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ABSTRACT 

The  Internet,  the  World  Wide  Web  and  the  Multicast  Backbone  (MBone)  have 
been  used  in  a  variety  of  ways  for  distance  learning.  Video  Teleconferencing  (VTC) 
classrooms  have  obvious  value  and  utility  but  they  are  limited  to  communicate  with  only 
a  small  number  of  similar  VTC  facilities.  We  are  most  interested  in  open  solutions  which 
take  advantage  of  the  global  Internet.  Therefore  the  problem  addressed  by  this  thesis  is  to 
evaluate  the  specific  benefits  and  drawbacks  of  Internet  technologies  in  support  of 
distance  learning. 

This  thesis  includes  a  detailed  examination  of  MBone,  Asynchronous  Transfer 
Mode  (ATM)  and  the  Distributed  Interactive  Simulation  (DIS)  protocol  from  the 
perspective  of  distance  learning.  An  innovative  design  for  a  low-cost  Web/MBone- 
capable  classroom  is  presented.  Experimental  results  include  globally  multicasting  the 
IEEE  Autonomous  Underwater  Vehicle  (AUV  96)  conference  and  digitally  recording  the 
1996  Monterey  Bay  Web  Content  and  Access  Workshop. 

One  result  we  found  is  that  MBone  can  be  used  successfully  for  distance  learning 
purposes  despite  common  constraints  of  limited  (128  Kbps)  bandwidth.  A  further  result 
is  that  an  MBone  classroom  can  be  42%  as  expensive  as  a  VTC  classroom  if  an  SGI  Indy 
is  used  and  12%  as  expensive  as  a  VTC  classroom  if  a  PC  is  used  in  the  classroom. 
Consequently  many  schools  can  afford  Internet-based  distance  learning  using  the 
solutions  presented  in  this  thesis  even  though  they  cannot  afford  VTC  rooms. 


vi 


TABLE  OF  CONTENTS 


l.  INTERNET-BASED  DISTANCE  LEARNING . 1 

A.  INTRODUCTION . 1 

B.  BACKGROUND . 2 

C.  MOTIVATION . 3 

D.  THESIS  ORGANIZATION . 4 

n.  RELATED  WORK . 7 

A.  INTRODUCTION . 7 

B.  PREVIOUS  WORK . 7 

C.  CURRENT  WORK . 9 

D.  SUMMARY . 11 

m.  PROBLEM  STATEMENT . 13 

A.  INTRODUCTION . 13 

B.  PROBLEM  AND  METHODOLOGY . 13 

C.  SUMMARY . 15 

IV  MBONE  IN  NFS . 17 

A.  INTRODUCTION . 17 

B.  BACKGROUND . 17 

C.  MBONE/WEB  CLASSROOM  DESIGN . 19 

D.  LECTURE  HALL  CONFIGURATION . 19 

E.  REMOTE  CONFERENCE  MULTICAST  SUPPORT . 22 

F.  MODIFYING  MBONE  TOPOLOGIES . 23 

G.  REGARDING  MBONE  AND  DISTANCE  LEARNING . 25 


vii 


H.  SUMMARY 


25 


V.  ATM  MBONE-COMPAUBLE  DISTANCE  LEARNING . 27 

A.  INTRODUCTION . 27 

B.  BACKGROUND . 27 

C.  INFORMATION  ABOUT  ATM . 29 

D.  INTERNET  PROTOCOL  (IP)  COMPATIBILITY 

WITH  ATM  . 36 

E.  INTEGRATING  MULTICAST  AND  MBONE  WITH 

ATM  37 

F.  ARRANGING  LONG-HAUL  ATM  CONNECTIONS . 39 

G.  NPS  ATM  LAN  REPORT . 40 

H.  BAYNET  REPORT . 43 

I.  REGARDING  ATM  FOR  MBONE-COMPATTBLE 

DISTANCE  LEARNING . 44 

J.  SUMMARY  . 46 

VI.  DISTRIBUTED  INTERACTIVE  SIMULATION  (DIS) 

PROTOCOL  AND  MBONE . . . . . 47 

A.  INTRODUCTION . 47 

B.  BACKGROUND . 47 

C.  DIS  PROTOCOL . 48 

1.  Introduction . 48 

a.  Protocols  for  Data  Interchanging . 49 

b.  Communication  Architecture . 49 

viii 


c.  Security . 49 

d.  World  Environment  Representation . 49 

e.  Computer  Generated  Forces  ( CGF) . 49 

2.  Network  Requirements  for  DIS . 50 

a.  Having  Real-Time  Simulations . 50 

b.  Multicasting . 52 

c.  Security  Issues . 52 

d.  Capacity  of  a  Network . 52 

3.  Problems  with  DIS . 53 

a.  Great  Amount  of  Bandwidth  and 

Computation  Requirement . 53 

b.  Security . 53 

c.  Multiplexing/Demultiplexing  of  Media . 54 

d.  Others . 54 

4.  Possible  Solutions  to  Problems . 54 

D.  DISANDMBONE . 56 

E.  SUMMARY  . 58 

Vn.  EXPERIMENTAL  RESULTS . 59 

A.  INTRODUCTION . 59 

B.  MBONE  CLASSROOM . 59 

1.  Goals  . 59 

2.  Hardware . 60 

3.  Software . 64 


IX 


4.  Topology . 65 

5.  Results . 66 

C.  AUV  96  CONFERENCE . 67 

1.  Goals  . 67 

2.  Hardware . 68 

3.  Software . 70 

4.  Topology . 70 

5.  Results . . . 71 

D.  MONTEREY  BAY  WEB  CONTENT  AND  ACCESS 

WORKSHOP . 72 

1.  Goals  . 72 

2.  Hardware . 73 

3.  Software . 76 

4.  Topology . 76 

5.  Results . 78 

E.  SUMMARY  . 78 

Vin.  CONCLUSIONS  AND  RECOMMENDATIONS . 79 

A.  CONCLUSIONS . 79 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK . 79 

APPENDIX  A.  CONHGURING  COMPUTERS  FOR  A  NEW 

SUBNET . 81 

APPENDIX  B.  MBONE  RELATED  INFORMATION . 85 

APPENDIX  C.  ABBREVIATIONS  AND  DEFINITIONS . 89 


X 


APPENDIX  D.  ON-LINE  AVAILABILITY  OF  THESIS 

PRODUCTS . 91 

APPENDIX  E.  BUILDING  AND  RUNNING  MBONE/WEB 

CLASSROOM . 93 

APPENDIX  F.  PLANNING  AND  MANAGING  A  MULTICAST 

SESSION  FOR  AUV  96  CONFERENCE . 107 

APPENDIX  G.  PRICE  COMPARISON  OF  MBONE  AND  VTC . 115 

LIST  OF  REFERENCES  . 119 

INITIAL  DISTRIBUTION  LIST . 123 


XI 


xii 


LIST  OF  FIGURES 


Figure  4. 1  Some  Drawbacks  of  VTC . 18 

Figure  4.2  Example  Use  of  MB  one  in  Distance  Learning . 20 

Figure  4.3  Benefits  of  Web/MBone  Classrooms  for  the  Schools . 21 

Figure  4.4  Some  Disadvantages  of  Web/MBone  Classrooms . 21 

Figure  4.5  Some  Necessary  Conditions  to  Achieve  MBone 

Distance  Learning . 26 

Figure  5. 1  53-Byte  ATM  CeU . 29 

Figure  5.2  An  ATM  Topology  Using  Both  Public  and  Private 

UNI . 30 

Figure  5.3  UNI  Cell  Header  Format . 31 

Figure  5.4  NNI  Cell  Header  Format . 32 

Figure  5.5  SONET/SDH  Frames  Used  To  Transmit  Data . 35 

Figure  5.6  Peer-to-Peer  ATM  Without  Any  Switch . 40 

Figure  5.7  ATM  LAN  With  One  ATM  SAvitch . 40 

Figure  5.8  ATM  LAN  Simulation  By  Using  Two  Nearby  ATM 

Switches . 41 

Figure  5.9  ATM  LAN  Configuration  With  Two  ATM  Switches 

In  Seperate  Places . 41 

Figure  5. 10  NPS  ATM  Connection  With  UCSC . 42 

Figure  5.11  Significant  Problems  with  ATM . 45 

Figure  6. 1  Entity  State  PDU . 51 

Figure  7. 1  General  Apperance  of  the  Classroom . 60 

xiii 


Figure  7.2  Power  and  Network  Conditions  Of  The  Classroom . . . 61 

Figure  7.3  Original  Ceiling  Lights  of  the  Classroom-only  two  banks  had ...  62 

separate  switches 

Figure  7.4  One  Idea  For  Extra  Lights.  Lights  Over  Trails  On 

The  Wall . 62 

Figure  7.5  Two  Fluorescent  At  The  Back  Are  Controlled 

Separately . 63 

Figure  7.6  The  Back  Lights  In  The  Classroom  Are  Turned  On  Separately 

And  All  Four  Banks  Are  Now  Independent . 63 

Figure  7.7  Hardware  Configuration  of  the  Classroom . 66 

Figure  7.8  Hardware  Configuration  of  AUV  96  Conference 

Room . 70 

Figure  7.9  Workstation,  PC,  TV  Monitor  and  VCR  Configuration . 71 

Figure  7. 10  A  General  Appearance  from  the  Conference . 72 

Figure  7.11  An  Example  of  Video  Quality  of  MBone  Tools . 72 

Figure  7.12  Author  Monitoring  Conference  Multicast . 73 

Figure  7.13  NPS  Mechanical  Engineering  Auditorium 

Amphitheater . 75 

Figure  7. 14  Configuration  of  the  Auditorium  and  the  Control 

Booth . 77 

Figure  E.l  MBone  Classroom  Connections . 94 

Figure  E.2  Video  Camera  Power  Adapter’s  Back  Panel . 95 

Figure  E.3  VCR’s  Back  Panel  Connections . 95 


XIV 


Figure  E.4  Projector’s  Back  Panel  Connections  . . 96 

Figure  E.5  TV  Monitor’s  Back  Panel  Connections . 96 

Figure  E.6  Indy’s  Back  Panel  Connections . 97 

Figure  E.7  Session  Directory  Window . 98 

Figure  E.8  Create  New  Session  Window  in  Sdr . 99 

Figure  E.9  Session  Information  Window . 100 

Figure  E.  10  Select  a  Tool  Window . 100 

Figxire  E.l  1  Visual  Audio  Tool  (vat)  Window . 101 

Figure  E.l 2  Vat  Menu  Window . 102 

Figure  E.13  Microphone  Button  on  Vat  Window . 102 

Figure  E.14  Me  Window . 103 

Figure  E.15  Vic  Menu  Window . 103 

Figure  E.  1 6  Near  End  Picture  in  Me  Window . 104 

Figure  F.l  AUV  96  Conference  Configuration  and  Connections . Ill 

Figure  F.2  Vic  Menu  Window . 112 

Figure  G.  1  NPS  VTC  Classroom  Equipment  List . 115 

Figure  G.2  Web/MBone  Classroom  Equipment  and  Price  List . 116 


XV 


xvi 


ACKNOWLEDGMENT 


The  author  acknowledges  the  support,  encouragement,  and  patience  of  his  love, 
friend  and  wife  Belkis.  The  author  would  like  to  gratefully  acknowledge  the  patience, 
support  and  smiling  face  of  Don  Brutzman.  The  author  would  also  like  to  thank  to  Dr. 
Mike  Zyda,  Don  McGredor,  Milena  Cochran,  my  friend  Ridvan  Erdogan  and  aU 
information  infrastructure  research  group  (iirg)  members  for  their  help. 


XVll 


L  INTERNET-BASED  DISTANCE  LEARNING 


A.  INTRODUCTION 

This  thesis  explores  ways  of  creating  distance  learning  environments  using  the 
Internet.  Utilizing  the  Internet  includes  local-area,  regional  and  global  networks  connected 
to  the  Multicast  Backbone  (MBone)  and  Asynchronous  Transfer  Mode  (ATM)  to  augment 
standard  Internet  connectivity  with  high-bandwidth,  low-latency  links.  Distance  learning 
is  a  relatively  new  topic  related  to  video  conferencing.  Since  video  conferencing  has  tight 
limits  on  the  number  of  people  who  can  participate  and  is  expensive  to  install  and 
maintain,  the  idea  of  adapting  Internet-based  video  conferencing  for  distance  learning  is 
appealing. 

ATM  is  a  new  technology  that  is  being  investigated  by  many  researchers.  The 
major  features  of  ATM  that  are  important  to  distance  learning  are  high  bandwidth  and  low 
latency.  These  two  features  allow  full-motion  video,  real-time  audio,  and  interactive  3D 
applications  at  faster  rates  than  is  ordinarily  possible  using  standard  Internet  links. 

Each  topic  mentioned  above  is  quite  broad.  This  thesis  examines  each  from  the 
narrow  perspective  of  Internet-based  distance  learning.  Related  work  includes  establishing 
an  ATM  Local-Area-Network  (LAN)  at  the  Naval  Postgraduate  School  (NPS)  and 
connecting  to  the  Monterey  Bay  ATM  Network  (Monterey  BAYNET  ATM).  Related  work 
also  includes  examining  the  testbeds  in  the  U.S.  such  as  Bay  Area  Gigabit  Testbed 
NETwork  (BAGNET),  The  International  Wide-Area  Year  (I- WAY)  project  and  examining 
an  exemplar  application,  the  Chesapeake  Bay  Virtual  Ecosystem  Model  (CBVE). 
Furthermore  a  series  of  experiments  to  create  an  internetworked  distance  learning 
classroom  and  to  support  distance  learning  at  off-site  and  on-site  locations  are  performed. 
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The  basic  motivation  for  this  thesis  remains  using  the  existing  Internet  for  distance 
learning.  This  thesis  combines  knowledge  and  experiments  together  in  order  to  provide  a 
good  starting  point,  practical  examples  and  a  reference  for  successors  in  the  same  area  of 
research. 

B.  BACKGROUND 

Studies  on  the  MBone  started  in  1992.  Today  MBone  tools  are  available  for  almost 
all  platforms  including  PC’s.  Tools  for  the  Macs  are  expected  to  be  ported  soon.  The  first 
use  of  MBone  at  NPS  was  achieved  in  1993  by  Mike  Macedonia  and  Don  Brutzman  to  test 
the  NPSNET  real-time  virtual  environment  simulation  program  over  the  Internet 
[Macedonia  95]. 

Tracey  Emswiler  used  MBone  tools  to  multicast  Dr.  Richard  Hamming’s  course 
“Futine  of  Science  and  Engineering:  Learning  to  Learn”  in  real  time  over  the  global 
Internet  during  an  entire  quarter  [Emswiler  95].  This  was  the  first  full  academic  course 
multicast  globally.  MBone  has  often  been  used  for  multicasting  special  events, 
conferences  and  lectures.  Nevertheless  MBone  has  not  been  used  much  for  distance 
learning,  since  the  aggregate  global  bandwidth  for  MBone  is  limited  (500  Kbps)  and  there 
are  not  many  MBone  connections  around  the  world  (approximately  2800  LANs).  The 
number  of  MBone  users  continues  to  increase  slowly  but  exponentially.  Any  site  with 
adequate  bandwidth  (typically  Tl,  1.5  Mbps  or  better)  can  connect.  Multicast  connectivity 
will  continue  to  improve  since  native  multicast  support  is  built  into  the  next-generation 
Internet  Protocol  (IPv6). 

Studying  today’s  technology  encourages  us  to  think  about  the  future.  Video,  audio, 
3D  graphics  and  other  applications  may  work  fine  within  the  limitations  of  the  Internet  for 
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now,  but  the  increasing  demand  will  force  the  use  of  faster  technologies.  There  are 
currently  no  “real”  full-motion  video,  audio  and  3D  applications.  Many  competing 
demands  must  be  considered.  For  example,  the  process  of  compression/decompression 
conserves  bandwidth  but  also  increases  latency.  Interactive  3D  graphics  applications  may 
have  lower  bandwidth  demands  than  video  but  higher  throughput  in  terms  of  packets  per 
second.  Thus  any  experiments  and  any  conclusions  must  include  many  considerations. 

C.  MOTIVATION 

Widely  distributing  an  application,  whether  or  not  the  application  is  very  valuable 
and  useful,  is  mostly  dependent  upon  economics.  For  the  purpose  of  this  thesis,  the  author 
chose  to  follow  a  method  of  doing  things  that  is  affordable. 

Proprietary  commercial  video  teleconferencing  is  an  expensive  application  to 
install  and  maintain  in  secondary  public  schools.  Video  conferencing  requires  modified 
classrooms,  special  equipment,  and  dedicated  connections.  However  MBone  classrooms 
are  less  of  an  investment  since  they  use  the  Internet.  Free  MBone  software  tools  are 
available  for  most  computers.  Ordinary  and  inexpensive  video  cameras  and  display 
monitors  can  usually  be  provided  at  any  location.  This  type  of  equipment  does  not  require 
trained  personnel  to  build,  maintain,  or  operate.  Thus  open  Internet-based  solutions  are 
appealing.  This  thesis  demonstrates  working  solutions  for  distance  learning  using  MBone. 

Another  motivation  for  this  thesis  is  to  give  conditions  and  steps  to  multicast 
lectures  with  the  least  effort  and  money.  Augmenting  a  conference  or  lecture  haU  with 
MBone  capability  is  not  prohibitively  costly.  Connecting  classrooms  now  appears  feasible 
and  straightforward. 

Another  motivation  in  this  thesis  is  to  explore  distance  learning  using  ATM. 
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Unfortunately  significant  problennis  with  ATM  precluded  such  a  study.  Our  long-term 
goals  include  building  large-scale  virtual  environments  (LSVEs)  using  ATM  links  and  the 
existing  Internet,  by  using  the  Virtual  Reality  Modeling  Language  (VRML)  and 
developing  a  virtual  reality  transfer  protocol  (vrtp)  [Brutzman  96]. 

D.  THESIS  ORGANIZATION 

Following  this  introduction,  the  related  work  chapter  examines  previous  and 
current  works  related  to  this  thesis.  The  problem  statement  chapter  explains  the  main 
problems  that  are  taken  as  the  reason  for  this  research.  The  subsequent  chapter  documents 
the  idea  of  MBone  and  its  use  at  NFS.  The  ATM  chapter  summarizes  ATM  concepts  for 
readers  to  let  them  understand  how  ATM  relates  to  distance  learning.  The  DIS  chapter 
does  the  same  thing  for  DIS  by  emphasizing  use  of  DIS  with  MBone  for  distance  learning. 
The  experimental  results  chapter  examines  three  major  experiments  performing  during 
this  research  and  evaluates  their  results.  The  experiments  are  building  an  MBoneAVeb 
classroom,  multicasting  the  AUV  96  conference  globally  through  the  Internet  by  using 
MBone,  and  digitally  recording  the  Monterey  Bay  Web  content  and  access  workshop  with 
MBone  software  tools.  The  conclusions  and  recommendations  chapter  has  both  the  results 
of  the  thesis  and  reconamendations  for  the  future  work.  Following  the  chapters,  the  first 
appendix  explains  how  to  connect  computers  to  a  new  network.  The  second  appendix  is  a 
kind  of  starter  kit  for  MBone  that  gives  the  Internet  sites  for  downloading  MBone  software 
arid  getting  information  about  MBone.  The  subsequent  appendix  has  abbreviations  and 
definitions  used  in  the  thesis.  Appendix  D  gives  the  on-line  retrieval  information  for  this 
thesis.  The  following  two  appendices  document  details  for  building  and  running  an 
MBoneAVeb  classroom,  as  well  as  planning  and  managing  the  AUV  96  conference 
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multicast.  The  last  appendix  documents  the  current  price  comparison  between  video 
teleconferencing  (VTC)  and  MBone  classroom. 
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II.  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  discusses  related  work  within  a  context  of  what  needs  to  be 
considered  when  using  the  Internet  and  MB  one  for  distance  learning.  This  chapter  also 
includes  related  work  on  Asynchronous  Transfer  Mode  (ATM)  usage  for  the  purpose  of 
distance  learning. 

There  are  few  examples  of  using  MBone  for  distance  learning  in  the  same  way  as 
presented  in  this  study.  Summaries  in  this  chapter  include  previous  and  current  work  on 
MBone  and  distance  learning. 

B.  PREVIOUS  WORK 

1.  An  Analysis  of  Internet’s  MBone:  A  Media  Choice  Perspective:  [Gambrino  94]- 
This  master’s  thesis  examines  the  effectiveness  of  Internet’s  Multicast  Backbone  (MBone) 
compressed-motion  video-teleconferencing  system  {vat  and  nv  circa  1994)  and  analyzes 
its  capabilities  and  limitations.  The  analysis  follows  the  media  richness  model  of  media 
choice  and  discusses  seven  influences  on  a  manager’s  media  selection.  This  study  focuses 
on  human-factors  considerations  of  distance  learning  using  compressed-motion  video¬ 
teleconferencing. 

2.  Desktop  Videoconferencing:  Technology  and  Use  for  Remote  Seminar  Delivery: 
[Rettinger  95]-  A  master’s  thesis  that  investigates  the  current  state  of  desktop 
videoconferencing  technology  and  evaluates  the  potential  effectiveness  of  this  technology 
for  delivering  interactive  seminars  to  a  remote  audience.  All  aspects  of  desktop  video 
conferencing  are  discussed  in  this  study.  A  weekly  seminar  class  was  multicast  using  the 
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Internet  MB  one  to  demonstrate  the  use  of  desktop  video  conferencing  for  distance 
learning. 

3.  Using  the  Multicast  Backbone  (MBone)  for  Distance  Learning:  [Emswiler  95]- 
A  master’s  thesis  that  documents  the  viability  and  impact  of  distance  learning  using  the 
MBone.  The  case  study  documents  the  learning  points  derived  from  the  successful  world¬ 
wide  multicast  of  the  Dr.  Richard  Hamming  course  “Learning  to  Learn.”  The  research 
provided  complete  course  coverage,  world- wide,  for  a  full  academic  quarter.  This  is  the 
first  documented  attempt  of  extending  traditional  education  methods  using  die  MBone. 

4.  Internetworking:  Planning  and  Implementing  a  Wide-Area  Network  (WAN)  for 
K-12  Schools:  [Bigelow  95]-  A  master’s  thesis  documenting  the  design  of  a  regional 
network,  Monterey  BayNet.  Monterey  BayNet  is  the  network  that  coimects  kindergarten 
through  twelfth  grade  (K-12)  students,  educators  and  research  institutions  throughout 
Monterey  and  Santa  Cruz  counties  on  the  central  Cahfornia  coast.  This  case  study  was  the 
first  step  toward  a  networked  approach  for  distance  learning  in  Monterey  Bay  area. 

5.  Bay  Area  Gigabit  Testbed  (BAGNET)-  Fourteen  organizations  within  the  San 
Francisco  Bay  Area  formed  a  gigabit  testbed  to  develop  and  deploy  the  computer 
multimedia  network  infrastructure  needed  to  support  a  diverse  set  of  distributed 
applications  in  a  large  scale,  metropolitan  ATM  network  environment.  In  this  project, 
ATM  technology  is  used  in  large-scale  teleseminars,  distributed  storage  and  on-line 
multimedia  libraries  in  order  to  show  the  capabilities  of  a  future  Internet.  The  BAGNET 
home  page  has  the  information  about  the  work  in  detail  [BAGNET  95]. 

6.  Monterey  Bay  ATM  Network  (BAYNET)  -  Pacific  Bell  awarded  two  years’  firee 
usage  of  the  company’s  ATM  service  to  regional  testbed  consortia  under  the  CalREN 
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(California  Research  and  Education  Network)  program.  The  Monterey  Baynet  ATM 
connectivity  was  funded  by  CalREN  program.  Attempted  applications  in  BAYNET 
include  distance  learning  between  UCSC  (University  of  Cahfomia,  Santa  Cruz)  and  UC 
Extension,  and  also  distance  learning  between  Monterey  Bay  Aquarium  (MBA), 
Monterey  Bay  Aquarium  Research  Institute  (MBARI)  using  the  Bay  Link  application 
which  provides  a  live  video  link  between  MBA/MBARI  and  San  Jose  Tech  Museum  of 
Innovation  (SJTMI). 

7.  NFS  Network  Simulator  (NPSNET)-  The  NPSNET  networked  virtual 
environment,  developed  at  the  Computer  Science  Department  of  the  Naval  Postgraduate 
School  (NFS)  in  Monterey,  California  was  the  first  distributed  virtual  environment 
simulation  that  was  played  over  the  global  Internet  using  MBone-compatible  Distributed 
Interactive  Simulation  (DIS)  protocol  [Macedonia  95].  This  work  is  especially  important 
since  it  demonstrates  a  new  class  of  applications  for  the  Internet.  Distributed  3D  real-time 
environments  are  also  important  for  the  future  of  distance  learning. 

8.  Remote  Seminars  through  Multimedia  Conferencing:  Experiences  from  the 
MICE  project  [Sasse  94]-  The  aim  of  the  MICE  (Multimedia  Integrated  Conferencing  for 
Europe)  project  is  to  enable  useful  internetworking  between  European  researchers  via 
multimedia  conferencing  technology. 

C.  CURRENT  WORK 

1.  Multimedia  European  Research  Conferencing  Integration  (MERCI)  [MERCI]- 
The  goal  of  this  project  is  to  pilot  interworking  between  Etiropean  researchers  and  also  to 
connect  to  sites  in  the  U.S.  using  existing  facilities.  This  project  is  a  successor  to 
Multimedia  Integrated  Conferencing  for  European  Researchers  (MICE)  (which  ended  in 
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September  1995)  with  additional  emphasis  on  the  integration  of  individual  software  tools 
and  their  porting  to  diverse  platforms  and  networks.  The  MERCI  system  currently  allows 
multimedia  conferencing  (audio,  video,  and  shared  workspace)  between  conference  rooms 
and  workstation-based  facilities,  hardware  and  software  codecs,  packet-switched  networks 
and  ISDN,  using  both  unicast  and  multicast  technology. 

2.  Internetworking:  NFS  ATM  LAN:  [Courtney  96]-  A  master’s  thesis  that 
documents  the  installation  of  ATM  technology  at  NFS.  The  objective  of  this  case  study  is 
to  create,  test,  and  build  an  ATM  network  to  support  real-time  tele-education  and  digital 
interactive  multimedia.  This  case  study  was  intended  to  be  one  foundation  for  this  thesis, 
experimenting  with  ATM  capabilities,  and  building  an  ATM  backbone  for  future  use  in 
distance  learning  and  other  high  bandwidth  low-latency,  multicast  applications.  However, 
the  research  concluded  that  ATM  is  currently  a  failure,  due  to  the  following  reasons: 

•  There  is  an  interoperability  problem  among  the  ATM  switches. 

•  ATM  is  currently  incompatible  with  IP  multicast. 

•  Long-haul  setup  is  a  time  consuming  process  and  the  fees  for  the  links  are 
prohibitively  expensive. 

•  People  that  really  understands  ATM  networks  are  few.  Therefore  there  is  a 
human  engineering  problem. 

»  There  is  a  crossover  problem.  When  one  connection  is  broken  then  there  is  no 
alternative  connection  to  carry  on  the  link. 


3.  Internetworking:  Implementation  of  Multicast  and  MBone  Over  Frame  Relay 
Network:  [Erdogan  96]-  A  master’s  thesis  that  documents  the  implementation  of  MBone 
over  Monterey  BayNet  for  educational  purposes.  It  documents  the  requirements  for  re¬ 
configuration  of  Monterey  BayNet  sites  to  join  MBone.  It  shows  that  MBone  over  Frame 
Relay  networks  is  possible  and  the  current  MBone  technology  provides  excellent 
performance  even  on  low-speed  network  connections.  This  thesis  is  especially  helpful  to 
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show  how  to  configure  and  use  MBone  in  networks  which  may  possibly  be  used  by  the 
schools  for  distance  learning  purposes. 

4.  The  Chesapeake  Bay  'Virtual  Ecosystem  (CBVE)  Model-  This  model 
incorporates  linked  submodels  of  various  organic  and  inorganic  substances  with  various 
oceanographic  processes  aU  of  which  will  be  spatially  and  temporally  linked  via  three- 
dimensional  Chesapeake  Bay  circulation  model  [Wheless  96].  Future  goals  include 
integrating  this  project  completely  with  the  Web,  and  showing  the  functionality  of  using 
the  Internet  to  import  or  export  any  type  of  media,  including  the  generation  of  3D  graphics 
object  models  compatible  with  the  "Virtual  Reality  Modeling  Language  CVRML)  [Carey 
96]. 

5.  Internetworking:  Economical  Storage  and  Retrieval  of  Digital  Audio  and  Video 
for  Distance  Learning:  [Tiddy  96]-  A  master’s  thesis  that  documents  the  testing  and 
comparison  of  currently  available  methods  of  digital  audio  and  video  storage  and  the  use 
of  current  transfer  modes  and  protocols  for  on-demand  retrieval  over  the  Internet.  This 
case  study  is  relevant  to  this  thesis  by  demonstrating  digital  storage  of  distance  learning 
recordings  for  later  retrieval  over  the  Internet. 

D.  SUMMARY 

In  this  chapter,  related  work  concerning  MBone  and  ATM  in  distance  learning  are 
summarized.  One  section  consists  of  previous  work  and  the  other  consists  of  current  work. 
Studies  that  involve  distance  learning  were  not  found,  presumably  due  to  the  newness  of 
ATM  technology. 
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ni.  PROBLEM  STATEMENT 


A.  INTRODUCTION 

This  chapter  defines  and  explains  the  problems  of  the  thesis.  Methodology, 
expected  solutions  to  the  problems  encountered  and  success  criteria  are  also  described. 

B.  PROBLEM  AND  METHODOLOGY 

The  Internet,  the  World  Wide  Web  and  the  Multicast  Backbone  (MBone)  have 
been  used  in  a  variety  of  ways  for  distance  learning.  However,  it  is  not  clear  how 
practical  they  are  as  an  affordable  alternative  to  proprietary  commercial  video- 
conferencing  systems.  Video  Teleconferencing  (VTC)  classrooms  have  obvious  value 
and  utility,  but  they  are  limited  to  communication  with  only  a  small  number  of  similar 
VTC  facilities.  This  study  is  interested  in  open  solutions  which  take  advantage  of  the 
global  Internet.  Therefore,  the  problem  addressed  by  this  thesis  is  to  determine  various 
benefits  and  drawbacks  of  Internet  technologies  in  support  of  distance  learning. 

Specific  goals  include  use  of  the  Internet  and  the  MBone  for  distance  learning 
purposes,  and  to  demonstrate  the  feasibility  of  a  Web/MBone  classroom  by  building  it. 
Additionally,  the  classroom  needs  to  be  affordable  so  that  schools  which  do  not  have  large 
budgets  may  participate  in  global  distance  learning.  The  ultimate  Web/MBone  classroom 
must  be  both  simple  and  affordable.  By  simple,  we  mean  that  it  can  be  built,  used  and 
maintained  by  anybody  (students  or  instmctors)  with  no  special  training  on  the  system. 
The  classrooms  should  make  use  of  all  facilities  of  the  Internet  such  as  Web  pages,  global 
multicast  of  audio/video. 

MBone  tools  have  been  used  experimentally  on  several  occasions  throughout  the 
world  in  the  last  few  years.  Our  plan  was  to  experiment  with  MBone  in  a  systematic  way 
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by  increasing  capacity  within  a  changing  environment.  Success  is  defined  as  building  and 
running  an  affordable  Web/MBone  classroom,  experimenting  with  MBone  for  larger 
functions  like  workshops  or  conferences,  and  evaluating  the  results  of  these  experiments 
for  future  researchers.  The  major  point  of  this  evaluation  is  to  be  able  to  recommend  to 
other  educational  organizations  how  to  use  MBone  for  distance  learning.  We  provide  a 
reference  for  building,  running  and  maintaining  Web/MBone  classrooms  to  assist  others  in 
participating  in  global  distance  learning.  We  also  examine  the  suitability  of  Asynchronous 
Transfer  Mode  (ATM)  networking  for  high-bandwidth  distance  learning,  and  the 
Distributed  Interactive  Simulation  (DIS)  protocol  for  large-scale  virtual  environments 
(LSVEs). 

The  first  step  in  reaching  these  goals  is  to  build  a  Web/MBone  classroom  using 
inexpensive,  available  equipment.  In  this  case,  the  equipment  was  borrowed  firom  different 
departments  in  the  school.  Evaluation  of  these  results  shows  that  MBone  can  be  used  for 
distance  learning  comfortably  and  effectively. 

After  evaluation  of  classroom  environment,  the  Web/MBone  classroom  equipment 
is  used  and  evaluated  in  other  environments  to  learn  about  other  Internet-based  distance 
learning  opportunities.  Subsequent  steps  in  this  evaluation  include  multicasting  a  large 
conference  globally,  and  multicasting  a  small  workshop  from  an  auditorium  to  test  digital 
recording.  Digital  recording  is  another  important  issue  for  the  storage  of  Internet  distance 
learning.  The  auditorium  experiment  gave  practical  experience  on  storing  MBone  sessions 
digitally  and  moving  them  through  Internet  when  necessary. 
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C.  SUMMARY 


The  problem  examined  in  this  thesis  is  to  evaluate  the  specific  benefits  and 
drawbacks  of  Internet  technologies  in  support  of  distance  learning.  Open  solutions  which 
take  advantage  of  the  global  Internet  are  the  main  interest.  Goals  are  to  include  use  of  the 
Internet  and  the  MBone  for  distance  learning  and  to  demonstrate  the  feasibility  of  a  Web/ 
MBone  classroom  as  well  as  the  low  cost.  Success  is  having  a  working,  affordable  Web/ 
MBone  classroom  and  showing  the  usage  of  MBone  for  distance  learning  purposes. 
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IV.MBONEATNPS 


A.  INTRODUCTION 

This  chapter  documents  recent  Multicast  Backbone  (MBone)-related  work  at  NFS. 
The  first  section  gives  background  information  on  the  experiments  at  NFS.  The  second 
section  presents  the  ideas  behind  the  design  of  a  MBone/Web  classroom,  as  well  as  the 
pros  and  cons  of  using  MBone  in  a  distance  learning  classroom,  a  lecture  hall,  and  a 
conference.  The  requirements  for  each  kind  of  event  are  presented  in  detail,  including 
directions  on  how  to  connect  to  MBone.  The  concluding  section  presents  some  ideas  on 
achieving  distance  learning  at  NFS  or  in  any  other  organization. 

B.  BACKGROUND 

The  MBone  was  named  by  Steve  Casner  and  has  been  around  since  early  1992 
[Casner  92].  The  MBone  is  a  virtual  network  that  is  layered  on  top  of  portions  of  the 
physical  Internet  to  support  routing  of  IF  multicast  packets.  Because  multicast 
connectivity  has  not  yet  been  integrated  into  some  production  routers  unicast  tunnels  are 
sometimes  used  to  pass  multicast.  Most  vendors  have  provided  native  IF  multicast  into 
their  recent  routers. 

Multicast  (unlike  unicast  or  broadcast)  supports  selectable  one-to-many  and 
many-to-many  connections  over  the  Internet.  Class  D  Internet  addresses  (which  have  a 
first-byte  value  between  224  and  239)  are  reserved  for  IF  multicasting. 

On  the  Internet,  there  are  link  layer  technologies  that  naturally  support  multicast 
(such  as  Ethernet  and  FDDI).  These  subnets  are  linked  by  virtual  point-to-point  links 
called  “tunnels”  since  some  regular  IF  routers  do  not  support  multicast.  At  the  endpoints 
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of  a  tunnel,  there  are  multicast  routers  (mrouters)  that  encapsulate  the  multicast  packets 
within  an  IP  header  and  then  send  them  through  the  tunnel.  The  receiving  side  is  also  an 
mrouter.  It  removes  the  IP  header  and  deliver  the  packet  to  its  group  address.  Mrouters  are 
usually  workstation-class  machines  having  operating  system  support  for  IP  multicast  and 
running  the  public-domain  “mrouted”  multicast  routing  daemon. 

NPS  has  been  working  with  the  MBone  for  several  years.  Dr.  Richard  Hamming’s 
“The  Art  of  Science  and  Engineering:  Learning  to  Learn”  course  was  multicast  using  the 
Internet  by  using  MBone  tools  called  Network  Video  (nv)  for  video  and  Visual  Audio  Tool 
(vat)  for  audio  in  Spring  1995  [Emswiler  95].  This  experiment  proved  that  the  MBone  is  a 
viable  asset  for  distance  learning. 

Studies  so  far  have  merely  shown  that  the  MBone  can  be  feasibly  used  for 
video/audio  transmission  in  a  multicast  environment.  This  thesis  examines  ways  that 
distance  learning  might  use  MBone  easily  and  effectively  on  a  regular  basis. 

In  recent  years  there  has  been  a  large  emphasis  (and  expenditure  of  funds)  on 
Video  Tele  Conferencing  (VTC).  Significant  drawbacks  exist  with  this  approach 
(Figure  4.1). 

•  VTC  is  expensive  (special  purpose  equipment,  connections,  etc.) 

•  VTC  equipment  is  not  completely  standardized  yet 

•  VTC  needs  specially  trained  personnel  to  operate  and  maintain  it 

•  VTC  is  capable  of  few  simultaneous  connections  (maximum  7  to  10) 

Figure  4.1.  Some  drawbacks  of  VTC. 

In  comparison,  using  the  existing  Internet  and  MBone  anywhere  in  the  world  costs 
almost  nothing,  is  easy  to  install,  is  easy  to  use  and  maintain,  and  has  the  capability  of 
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connecting  numerous  sites  simultaneously.  These  are  important  reasons  for  choosing 
MBone  instead  of  VTC  for  distance  learning  purposes.  We  therefore  look  at  these  issues  in 
detail. 

C.  MBONE/WEB  CLASSROOM  DESIGN 

The  Internet  is  an  undeniably  good  reference  source.  On  the  Internet,  the  World 
Wide  Web  (Web  or  WWW)  allows  for  new  dimensions  in  communication  and  vision.  Any 
individual  or  institution  can  have  a  home  page  on  the  Internet  That  has  increased  the 
usage  of  the  Internet  for  reference.  Search  engines  made  information  easy  to  find.  Static 
slides  can  be  replaced  with  projections  of  the  relevant  home  page  screens  in  lectures  and 
conferences.  Addition  of  the  MBone  allows  users  to  include  interactive  audio  and  video 
during  a  lecture  or  a  conference.  Therefore  the  idea  of  combining  web  browsing  and  the 
MBone  in  a  lecture  is  a  good  idea  for  distance  learning  experiment.  The  lecture  can  be 
transmitted  to  several  sites  through  MBone,  and  participants  at  either  the  near  or  far  end 
can  follow  the  instructor  with  MBone  tools  and  Web  browsers  (Figure  4.2). 

These  ideas  are  the  main  motivation  for  a  MBoneAVeb  classroom.  Potential 
benefits  are  summarized  in  Figure  4.3  and  potential  drawbacks  are  in  Figure  4.4. 

D.  LECTURE  HALL  CONFIGURATION 

Lecture  halls  are  different  than  ordinary  classrooms.  First  of  all,  a  lecture  haU  may 
accommodate  100  people  or  more,  whereas  a  classroom  may  be  made  up  of  only  25-30 
people.  This  difference  makes  lecture  hall  configuration  more  difficult,  because  audio  and 
video  quality  are  more  important  for  larger  spaces.  These  factors  must  be  taken  into 
account  when  a  lecture  hall  is  configured  for  an  MBone  session  such  as  a  conference. 
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Microphones  and  camera(s)  must  be  placed  in  the  hall  very  carefully. 
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*  Building  an  MBoneAVeb  class  is  much  cheaper  than  building  a  video 
conference  room.  More  specifically,  the  equipment  used  in  MBone  is  ordinary 
equipment  and  consequently  easier  to  find  and  purchase  (or  borrow),  and  you 
do  not  need  to  pay  extra  money  for  the  connection  as  in  case  of  video 
conferencing. 

•  It  is  easy  to  use  the  room  and  it  does  not  have  to  adhere  to  a  strict  schedule. 

•  Since  the  system  accepts  any  kind  of  computers  and  any  kind  of  connections, 
it  is  easier  to  distribute  through  out  any  school. 

♦  A  lecture  or  a  conference  can  be  sent  and  received  by  all  MBone-capable 
networks  around  the  world  simultaneously. 

Figure  4.3.  Benefits  of  Web/MBone  classrooms  for  the  schools. 

•  Video  conferencing  rooms  are  usually  separate  and  secured  rooms,  but 
MBoneAVeb  classrooms  are  ordinary  rooms  so  that  they  are  not  necessarily 
secured.  As  a  result,  equipment  used  in  the  classroom  needs  to  be  secured. 

•  Since  everybody  can  use  the  rooms  for  his/her  own  purposes,  it  is  a  little  bit 
difficult  to  maintain  the  rooms,  and  follow  the  activities  of  people  using  the 
rooms.  It  is  not  necessarily  a  requirement  to  use  MBone  or  Web  for 
scheduling  a  class  in  that  particular  room. 

•  Since  the  equipment  used  may  be  borrowed  from  a  system  administrator 
from  another  department,  equipment  can  go  back  and  forth  for  reasons  not 
related  to  MBone. 

Figure  4.4.  Some  Disadvantages  of  Web/MBone  Classrooms. 

Another  factor  is  that  the  quality  of  the  audio  equipment  used  in  lecture  halls  may 
need  to  be  higher  than  that  used  in  classrooms,  because  the  noise  in  the  lecture  haU  created 
by  a  larger  number  people  must  not  be  multicast.  The  best  thing  that  can  be  done  is  to  use 
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built-in  house  audio  (public  address  system),  if  available  for  this  purpose,  and  connect  it  to 
the  computer  system. 

Since  lecture  halls  are  usually  open  for  public  use  in  schools,  assigning  dedicated 
computer,  audio  and  video  systems  to  the  halls  is  almost  impossible.  The  problem  with 
computers  that  are  not  permanently  assigned  is  that  they  may  need  to  be  reconfigured  each 
time  they  are  moved  to  the  lecture  hall.  Configuration  of  host  numbers  and  network 
services  is  usually  a  painful  operation  for  system  administrators. 

MBoneAVeb  lecture  haUs  can  save  money  just  like  classrooms.  Instead  of  paying  a 
nearby  hotel  for  holding  a  conference  or  a  lecture,  using  their  own  assets  at  the  school  with 
zero  cost  is  attractive  to  many  administrators.  The  security  of  equipment  issue  is  also 
present  in  lecture  halls.  It  is  difficult  to  secure  a  lecture  hall  that  sees  regular  public  use. 

E.  REMOTE  CONFERENCE  MULTICAST  SUPPORT 

One  important  event  in  which  the  MBone  was  used  was  Autonomous  Underwater 
Vehicle  (AUV)  96  Conference  held  by  NFS  at  the  Hyatt  Regency  Hotel  in  Monterey 
between  2-6  June  1996.  The  three-day  conference  was  multicast  globally.  According  to 
remote  and  local  attendees,  the  conference  was  a  worthwhile  achievement  with  individuals 
watching  the  conference  on  their  computers  in  different  places  around  the  world.  On  the 
first  day  the  video  and  audio  quality  was  occasionally  poor,  but  after  students  became 
more  experienced  with  the  MBone  tools  and  video  cameras  quality  improved  day-by-day. 

Since  there  was  no  convenient  room  for  that  size  conference  in  the  school,  all  the 
MB  one-related  equipment  had  to  be  taken  to  the  conference  location.  The  biggest  problem 
was  a  lack  of  network  connections  in  the  hotel.  Thus  a  network  had  to  be  constructed. 
From  previous  experiments,  we  had  known  that  the  easiest  way  to  provide  a  network 
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connection  was  to  use  an  Airlan  bridge.  This  equipment  is  a  wireless  bridge  connected  to  a 
MBone-capable  subnet  at  the  school.  One  connection  is  a  main  unit  with  an  antenna  at  the 
school,  and  another  wireless  bridge  at  the  hotel  with  its  antenna  directed  back  to  the 
school  acts  as  a  repeater  between  the  hotel  and  the  school.  Details  about  the  topology  and 
configuration  may  be  found  in  Chapter  VII. 

Before  taking  the  assigned  computers  to  the  conference,  they  need  to  be  configured 
for  the  subnet  that  they  will  be  assigned.  MBone  tools  and  other  programs  need  to  be 
installed  locally  since  the  normal  network  file  system  (NFS)  wiU  not  be  available. 
Configuring  computers  for  a  different  subnet  is  explained  in  detail  in  Appendix  A. 

After  moving  the  necessary  gear  to  the  conference  hall,  every  item  must  be  tested 
as  if  the  conference  has  begun.  Even  though  the  equipment  initially  seems  to  be  working, 
a  system  administrator  must  be  present  to  help  with  inevitable  problems.  Most  of  the  time 
problems  are  related  to  the  system  configuration,  and  only  a  system  administrator  with 
root  permissions  can  fix  those  sort  of  problems. 

R  MODIFYING  MBONE  TOPOLOGIES 

Connecting  to  MBone  or  connecting  to  an  MBone  capable  networks  has  been 
mentioned  several  times.  In  this  section,  connecting  to  MBone  will  be  explained.  Before 
explaining  the  necessary  steps  to  join  the  MBone,  it  is  probably  better  to  define  a  few 
terms  that  will  be  used  in  the  reminder  of  the  chapter. 

Tunnel:  A  tunnel  is  a  point-to-point  connection  between  two  multicast  capable 
routers.  Since  the  Internet  uses  P  unicast  transmission  mode,  routers  have  to  send  their 
packets  in  IP  unicast.  They  can  not  recognize  the  multicast  D-t5q)e  IP  addresses.  So  the 
multicast  router  that  wants  to  send  a  multicast  packet  across  an  P  network  wiU  use  this 
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point-to-point  tunnel  connection  prepend  another  IP  header,  and  set  the  destination 
address  in  the  new  header  to  be  the  unicast  address  of  the  multicast  router  at  the  other  end 
of  the  tunnel. 

mrouterlmrouted:  End  points  of  a  tunnel  are  called  multicast  routers  (mrouters). 
They  are  in  charge  of  distributing  and  replicating  the  multicast  data  streams  to  their 
destinations  [Kumar  96].  They  are  usually  regular  workstations  that  run  a  multicast  route 
daemon,  (mrouted)  to  behave  as  an  mrouter.  Recently  most  new  IP  router  products  have 
begun  to  support  multicasting. 

MOSPF,  DVMRP:  The  Multicast  Extensions  to  Open  Shortest  Path  First  (MOSPF) 
is  defined  in  RFC-1584.  Distance  Vector  Multicast  Routing  Protocol  (DVMRP)  is  defined 
in  RFC- 1075.  They  are  two  different  kinds  of  multicast  routing  protocols  that  are  used  by 
mrouters  to  build  effective  routing  trees  to  transmit  multicast  packets  to  their  targets. 

The  procedure  to  join  the  MB  one  follows  [Macedonia  95].  First,  your  network 
provider  must  be  on  the  MB  one.  Otherwise  you  should  create  a  tunnel  to  a  network 
provider  near  you.  This  is  not  recommended  since  it  may  overload  links  with  duplicate 
tunnels  to  separate  end  nodes.  If  you  are  a  network  provider,  send  e-mail  to  the  request 
address  of  the  mailing  list  for  your  country  to  be  added  to  that  list  for  the  purposes  of 
coordinating,  setup  of  tunnels,  etc.  The  list  of  e-mail  addresses  is  in  Appendix  B. 

Second,  you  should  assign  a  Unix  workstation  to  be  the  mrouter.  Download 
mrouted  from  one  of  the  sites  listed  in  Appendix  B  in  the  Internet  and  install  it  on  the 
mrouter.  Change  the  /etc/mrouted.conf  file  according  to  your  requirements.  This  is  usually 
done  to  create  a  tunnel  between  you  and  a  site  on  the  MBone.  Build  a  kernel  with  IP 
multicast  extension  added  in  your  workstation  (if  it  is  not  already  built-in)  and  then  install 
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the  kernel. 


Lastly,  send  an  e-mail  to  your  Internet  service  provider  or  the  MBone  list  in  your 
region  asking  to  hook  in.  In  this  e-mail  you  will  include  “Request  for  tunnel”  as  the 
subject,  and  then  write  your  endpoint  configuration  information.  After  you  receive 
confirmation,  you  may  need  to  make  small  changes  in  your  /etc/mrouted.conf  file  to 
include  the  MBone  provider’s  tunnel  information.  After  that,  start  the  mrouted  daemon 
[Kumar  96].  You  test  your  MBone  tunnel  by  running  the  MBone  tools,  such  as  sdr  and  sd. 
More  information  about  each  step  can  be  found  at  the  addresses  in  Appendix  B. 

G.  REGARDING  MBONE  AND  DISTANCE  LEARNING 

Success  in  using  the  MBone  for  distance  learning  can  be  achieved  with  a  little 
funding  for  equipment  used  in  MBone,  and  by  encouraging  people  to  experiment  on 
MBone.  Some  of  the  necessary  conditions  to  achieve  MBone  distance  learning  are  shown 
in  Figure  4.5. 

H.  SUMMARY 

This  chapter  documents  the  use  of  MBone  for  distance  learning  at  NFS.  This 
information  includes  setting  up  an  MBoneAVeb  classroom,  configuring  a  lecture  hall, 
providing  multicast  support  to  a  conference,  and  connecting  to  the  MBone.  The  last 
section  lists  some  “must  do”  requirements  to  be  successful  in  using  different  aspects  of 
MBone  for  distance  learning  purposes. 
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•  Deploy  the  equipment  in  the  MBone  classroom  permanently.  Do  not  let 
other  users  change  the  configuration. 

•  After  setting  up  the  classroom  and  reaching  the  goal,  replace  all  the 
borrowed  gear  with  permanent  equipment. 

•  Carefully  record  configuration  for  the  classrooms  and  lecture  halls  in  your 
school,  in  order  to  rebuild  them  if  necessary. 

•  Learn  how  to  configure  the  computers,  since  it  is  not  always  possible  to  find 
a  system  administrator. 

•  MBone  documents,  programs  and  routers  must  frequently  be  updated  to 
gain  better  performance.  Configurations  and  other  information  on  the 
experiments  are  covered  in  Chapter  VH. 

Figure  4.5.  Some  Necessary  Conditions  to  Achieve  MBone  Distance  Learning. 
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V.  ATM  MBONE-COMPATIBLE  DISTANCE  LEARNING 

A.  INTRODUCTION 

This  chapter  examines  the  potential  use  of  ATM  for  distance  learning.  In  the 
“Background”  section  readers  can  find  information  on  three  generations  of  networking 
and  communications  history.  The  “Information  about  ATM”  section  describes  moving 
data  from  one  host  to  another  using  ATM,  packaging  data  into  cells  through  the  ATM 
layers,  and  the  transmission  media  used  for  ATM.  In  the  “Internet  Protocol  (ff ) 
Compatibility  with  ATM”  section  the  author  explains  how  unicast  IP  works  over  ATM  and 
recent  progress  in  that  area  of  the  technology.  The  “Integrating  multicast  and  MBone  with 
ATM”  section  deals  with  one  of  the  primary  themes  of  thesis,  which  is  distance  learning 
using  MBone  over  ATM.  This  section  also  examines  a  major  problem  with  ATM:  inability 
to  support  many-to-many  IP  multicast.  The  last  three  sections  describe  arranging  long- 
haul  ATM  connections,  ATM-related  work  at  NPS,  and  a  report  on  the  Bay  Area  Gigabit 
NETwork  (BAGNET). 

It  must  be  noted  that  original  expectations  for  this  chapter  included  experimental 
use  of  ATM  to  support  distance  learning.  Unfortunately  ATM  problems  encountered  in 
this  and  a  related  thesis  [Courtney  96]  prevented  accomplishing  meaningful  experimental 
results.  Nevertheless  this  chapter  provides  a  good  basis  for  continued  efforts  to  utilize 
ATM  for  MB  one-compatible  distance  learning. 

B.  BACKGROUND 

According  to  Sterbenz,  the  history  of  networking  and  communications  can  be 
divided  into  three  generations  [Sterbenz  95].  The  first  generation,  which  is  principally 
characterized  by  voice  communication,  entertainment,  and  data  networking,  ended  in  the 
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1970’s.  Voice  communication  was  achieved  using  analog  systems.  Entertainment  was 
broadcast  of  radio  and  television.  Data  communications  was  provided  by  connecting 
terminals  to  a  host  (by  serial  link  for  short  distances,  or  by  modem  for  long  distances). 

In  1980’s  second-generation  networking  introduced  the  Internet.  The  internal 
telephone  network  switches  and  trunks  became  digital  for  most  connections.  PBXs 
(Private  Branch  eXchange  telephone  switches)  and  mobile  communications  (cellular 
telephone  systems)  became  available.  In  the  entertainment  category,  cable  networks,  BBS 
(bulletin  board  systems)  and  on-line  services  (such  as  America  On  Line,  CompuServe,  and 
Prodigy)  became  utilized  in  daily  life.  In  data  networking,  remote  login  and  electronic 
mail  were  utilized  while  workstations  and  PCs  were  networked  using  Ethernet  and  token 
rings.  For  the  first  time  connection-oriented  networks  using  protocols  like  BNA,  DECNET 
and  SNA  became  available.  Because  the  differences  between  protocols  and  network 
architectures  were  incompatible,  most  networks  were  poorly  interconnected. 

In  the  third  (and  current)  generation,  the  voice,  entertainment  and  data  networking 
categories  are  merging.  Multimedia  communication  (data,  voice,  and  video)  runs  over  fast 
cell-switched  and  routed  networks  in  LANs  and  WANs. 

Increasing  demand  for  high  bandwidth  and  low  delay  over  long  distances  has  lead 
researchers  to  develop  several  high-speed  network  technologies  offering  data  rates  of 
hundreds  of  Mbps,  such  as  FDDI,  Frame  Relay,  Fast  Ethernet,  Ether  switch,  and  most 
recently  Asynchronous  Transfer  Mode  (ATM)  [Kavak  95]. 

Among  these  techniques,  ATM  has  generated  the  most  interest  due  to  its  apparent 
flexibility  and  support  of  multimedia  traffic.  ATM  is  well  suited  to  meet  most 
requirements  for  high-speed  networking. 
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C.  INFORMATION  ABOUT  ATM 


The  basic  purpose  of  ATM  is  to  prove  a  high-speed  low-latency  switching  network 
to  support  various  types  of  traffic  such  as  data,  voice  and  video.  In  order  to  achieve  this 
goal  ATM  segments  and  multiplexes  user  traffic  into  53  byte-segments  called  “cells” 
(Figure  5.1)  [Black  95]. 


■53  BYTES 


HDR 


DATA 


5  BYTES- 


48  BYTES' 


Figure  5.1  53-byte  ATM  Cell 


The  first  five  bytes  are  called  the  “cell  header”  and  are  used  by  User-to-Network 
Interfaces  (UNIs),  Network-to-Network  Interfaces  (NNIs)  and  switches  to  route  the  ceU. 
The  data  part  of  48  bytes  may  include  additional  overhead  bytes  as  well  as  data  [Partridge 
95]. 

There  are  two  distinct  forms  in  UNI,  described  in  [The  ATM  Forum  95].  Public 
UNI  interconnects  an  ATM  user  with  an  ATM  switch  in  a  public  service  provider’s 
network.  Private  UNI  interconnects  an  ATM  user  with  an  ATM  switch  in  the  same 
corporate  network.  Both  UNIs  share  the  ATM  layer  specification  but  they  may  use 
different  physical  media.  Public  UNI  facilities  used  in  connections  between  users  and 
switches  must  be  capable  of  spanning  long  distances,  whereas  in  private  UNI  the 
switching  equipment  is  located  a  limited  distance  from  the  user  device.  A  possible  ATM 
topology  using  both  public  and  private  UNI  is  shown  in  Figure  5.2.  The  UNI  cell  header 
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format  is  shown  in  Figure  5.3. 


Figure  5.2  An  ATM  Topology  Using  both  Public  and  Private  UNI.  After  [Black  95] 

NNI  is  utilized  to  provide  smooth  connections  between  independently  operated 
ATM  networks.  Since  the  purpose  of  NNI  is  different  than  UNI,  its  cell  header  format  is 
slightly  different  than  UNI.  In  the  NNI  cell  header  format  described  in  Figure  5.4,  12-bit 
Virtual  Path  Identifier  (VPI)  and  16-bit  Virtual  Circuit  Identifier  (VCI)  are  the  first  two 
fields.  VPI  and  VCI  together  form  a  unique,  28-bit  address  for  an  ATM  connection.  As  an 


example  and  to  explain  how  VPI  and  VCI  are  used,  suppose  that  every  ATM  cell  header  is 
a  telephone  number  that  covers  both  VPI  and  VCI  fields.  In  general,  a  telephone  number 
has  an  area  code  and  a  local  number,  such  as  (408)  372-4720.  In  this  example  408  is  the 
area  code  and  372-4720  is  the  local  number.  When  VPI  is  replaced  with  the  area  code  and 
VCI  with  the  local  number,  that  combined  information  provides  the  switches  with  the 
connection  between  two  end-points.  First  switches  look  at  the  VPI  to  determine  if  the 
number  is  local  or  not.  If  the  number  is  local,  the  switch  then  looks  at  the  VCI  number  and 
sends  it  to  the  destination,  otherwise  the  switch  uses  the  VPI  to  send  the  traffic  to  the  next 


switch,  to  repeat  the  same  procedure. 
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PT  IcLP 

CRC 
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GFC  (Generic  Flow  Control) 
VPI  (Virtual  Path  Identifier) 
VCI  (Virtual  Circuit  Identifier) 
PT  (Payload  Type) 

CLP  (Cell  Loss  Priority) 

CRC  (Cylic  Redundance  Check) 


Figure  5.3  UNI  CeU  Header  Format.  After  [Partridge  95] 


Payload  Type  (PT)  is  used  to  distinguish  between  user  traffic  and  different  types  of 
operations,  administration  and  management  traffic.  Cell  Loss  Priority  (CLP)  is  a  single  bit 
that  indicates  whether  a  cell  will  be  preferentially  dropped  in  the  presence  of  congestion. 
Header  Cyclic  Redundance  Check  (CRC)  is  an  error-detecting  code  part  that  is  utilized  for 
the  five-byte  ceU  header. 
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Figure  5.4  NNI  Cell  Header  Format.  After  [Partridge  95] 


The  main  difference  between  UNI  and  NNI  format  is  Generic  Flow  Control  (GFC) 
field  in  header  of  UNI  cell.  A  four-bit  GFC  field  gives  UNI  an  opportunity  to  negotiate 
with  the  shared-access  networks  about  how  to  divide  cells  of  the  different  ATM 
connections  into  the  network.  GFC  values  are  not  yet  defined.  A  value  of  zero  is  always 
used  in  this  field  [Partridge  95]. 

These  definitions  above  are  useful  in  understanding  the  terminology  of  a 
connection  between  two  end  points  and  to  make  a  connection  between  two  end  points. 
Two  new  terms  related  to  the  connection  are  Permanent  Virtual  Circuit  (PVC)  and 
Switched  Virtual  Circuit  (SVC). 

In  PVC  a  connection  is  established  according  to  a  request  firom  the  user,  using  the 
bandwidth  available.  Applications  may  use  the  bandwidth  reserved  for  the  connection. 
VPI  and  VCI  numbers  for  that  connection  are  permanent. 

In  SVC,  VPI  and  VCI  numbers  are  assigned  dynamically  by  intermediate 
switches,  producing  a  “connection-in-request”  type  system.  The  bandwidth  required  is 
allocated  by  the  switches  dynamically  according  to  the  band>vidth  that  is  available.  A 
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switch  receives  a  cell  on  an  incoming  port  and  reads  the  VPWCI  values.  These  values  are 
saved  for  future  recognition  of  a  specific  end  user.  The  switch  also  looks  through  a  routing 
table  to  find  a  matching  outgoing  VPI  for  the  incoming  one.  After  the  switch  finds  a 
match,  it  replaces  the  VPI  number  in  the  cell  header  with  the  new  one  and  sends  it  to  the 
outport  for  the  next  switch.  Notice  that  the  routing  table  must  be  built  before  the 
connections.  This  call  setup  process  illustrates  why  ATM  is  called  connection  oriented. 

So  far,  this  section  of  the  chapter  described  how  ATM  moves  data  from  one  point 
to  another.  ATM  sends  the  data  by  cells  over  a  connection.  At  this  point,  a  description  of 
how  data  is  packaged  into  the  cells  is  relevant.  This  packaging  process  is  carried  out  in 
ATM  Adaptation  Layer  (AAL).  Various  kinds  of  higher-level  data  such  as  datagrams, 
voice  samples,  and  video  frames  can  be  divided  into  series  of  cells  prior  to  being  sent  over 
an  ATM  connection.  They  are  subsequently  restored  to  the  original  stream  after  final 
receipt. 

Since  there  are  different  kinds  of  timing  requirements  for  data  transferred  through 
ATM  connections,  it  is  important  to  be  able  to  support  all  of  them.  Originally  the 
Consultative  Committee  on  International  Telephone  and  Telegraph  (CCITT  -  now  ITU) 
determined  four  different  types  of  service.  They  were: 

1.  Constant  bit-rate  applications  (CBR). 

Send  and  receive  data  at  constant  bit  rates  (e.g.  voice,  video) 

2.  Variable  bit-rate  applications  (VBR). 

Send  data  at  variable  bit  rates.  This  is  a  connection-oriented  service  that  requires 
timing  information  (e.g.  compressed  video  or  audio)  [Anujan  95]. 
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3.  Connection-oriented  data  applications. 

Intended  to  support  applications  that  use  a  basic  network  service  such  as  X.25 
[Partridge  95].  There  is  no  timing  information  requirement. 

4.  Connectionless  data  applications. 

Intended  to  support  datagram  networking  protocols  like  TCP/DP. 

AAL  numbers  have  been  given  to  each  of  these  services  listed  above.  AALl 

provides  CBR,  AAL2  provides  VBR,  AAL3  and  AAL4  (merged  into  AAL  3/4)  provides 

items  3  and  4  above.  However  it  was  decided  that  AAL  3/4  was  not  efficient  for  most  data 

communications  applications.  Therefore  a  more  efficient  AAL5  (also  called  as  Simple  and 

Efficient  Adaptation  Layer-  SEAL)  was  developed  for  this  purpose. 

Beneath  AAL  there  are  two  sublayers:  Segmentation  And  Reassembly  (S  AR) 

sublayer  and  Convergence  Sublayer  (CS).  SAR  sublayer  processes  user  PDUs  that  are 

different  in  size  and  format  into  ATM  cells  at  the  sending  site  and  reassembles  the  cells 

into  the  user-formatted  PDUs  at  the  receiving  site.  CS  multiplexes  and  performs  loss 

detection/timing  recovery,  depending  on  the  t3q)e  of  traffic  being  processed  by  the  AAL. 

According  to  [Black  95]  the  use  of  these  two  sublayers  in  ATM  is  as  follows: 

The  SAR  and  CS  entities  provide  standardized  interfaces  to  the  ATM  layer.  The 
ATM  layer  is  then  responsible  for  relaying  and  routing  the  traffic  through  the  ATM 
switch.  The  ATM  layer  is  connection  oriented  and  cells  are  associated  with 
established  virtual  connections.  Traffic  must  be  segmented  into  cells  by  the  AAL 
before  the  ATM  layer  can  process  the  traffic.  The  switch  uses  the  VPVVCI  label  to 
identify  the  connection  to  which  the  cell  is  associated  [Black  95]. 

The  last  topic  in  this  ATM  introduction  is  the  media  on  which  ATM  cells  are 

transmitted.  The  first  thing  of  importance  about  physical  media  is  that  ATM  cannot  be  put 

directly  over  a  fiber  optic  cable  or  a  wire  [Partridge  95].  Over  long  distances,  Synchronous 

Optical  NETwork  (SONET)  firames  are  used  to  encapsulate  ATM  cells.  SONET  is  also 
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known  as  Synchronous  Digital  Hierarchy  (SDH)  in  the  countries  other  than  the  U.S.  The 
first  data  rate  in  SONET/SDH  is  51.84  Mbps  which  is  designated  as  Optical  Carrier  level  1 
(OC-1)  or  Synchronous  Transport  Signal  level  1  (STS-1)  (in  countries  other  than  the 
U.S.).  The  rate  can  be  expressed  as  OC-n  where  n  is  a  multiplier  of  OC-1  (51.84  Mbps). 
For  instance  when  OC-12  is  referred  as  a  rate,  it  should  be  interpreted  as  51.84x12  = 
622.02  Mbps. 

SONET/SDH  uses  frames  for  transmit  data.  Each  frame  consists  of  90  columns 
and  9  rows.  Thus  one  frame  contains  9x90=810  bytes.  For  a  given  OC-n,  n  frames  are 
transmitted  as  a  single  unit  of  transmission.  So  for  instance,  OC-1  transmits  data  with 
single  frames  where  an  OC-3  does  the  same  thing  with  3  frame-groups  (Figure  5.5). 


SONET  is  not  the  only  physical  media  to  transmit  ATM  cells.  Other  compatible 
media  include  Digital  Signal  level  3  (DS-3)  which  is  44.736  Mbps,  100  Mbps  FDDI 
compatible  multimode  fiber  interface,  unshielded  twisted-pair  (UTP-51.84  Mbps),  and 
shielded  twisted  pair  (STP-155  Mbps)  [Anujan  95]. 
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D.  INTERNET  PROTOCOL  (IP)  COMPATIBILITY  WITH  ATM 


Interconnection  of  large-scale  LAN  and  WAN  networks  across  ATM  requires  a 
network  layer  protocol  such  as  the  Internet  Protocol  (IP).  The  operation  of  ATM  switches, 
the  primary  mechanism  for  interconnecting  current  LANs  and  WANs  across  ATM 
backbones,  needs  to  be  compatible  with  such  a  protocol  [Kavak  95]. 

In  the  so-called  classical  IP  over  ATM  model,  a  logical  IP  subnetwork  (LIS) 
consists  of  hosts  and  routers  having  the  same  subnetwork  address  and  netmask  [Kavak 
95],  Hosts  connected  to  the  same  subnet  (i.e.  LIS)  communicate  directly.  However, 
communication  between  two  hosts  on  different  LISs  is  only  possible  through  an  IP  router, 
regardless  of  whether  direct  ATM  connectivity  is  possible  between  these  two  hosts. 

Even  though  two  ATM  networks  may  be  connected  to  each  other  with  native  ATM 
through  ATM  switches,  inside  these  networks  there  may  be  IP  subnets.  So  the  problem  is 
to  make  IP  and  ATM  hosts  understand  each  other  by  some  means.  An  address  mapping  is 
necessary  between  IP  and  ATM  addresses.  IP  addresses  are  resolved  to  ATM  addresses  by 
use  of  an  ATM  Address  Resolution  Protocol  (ATM ARP)  service  in  LIS. 

Initially,  hosts  are  connected  to  the  ARP  server  inside  their  LIS  by  using  a  built-in 
ATM  address  in  the  ARP  server,  then  the  ARP  server  uses  Inverse  ARP  (InARP)  to 
determine  the  IP  and  ATM  addresses  of  the  host.  After  that  the  hosts  can  submit  a  request 
to  ARP  server  to  get  the  ATM  address  of  a  given  IP  address.  An  ARP  server  can  do  this 
job  only  for  hosts  in  the  same  subnet  [Kavak  95]. 

Although  the  classical  IP  over  ATM  is  conceptually  simple  and  does  not  require 
any  changes  to  existing  systems,  it  is  very  limited,  since  IP  routers  are  to  be  used  between 
ATM  subnets.  In  this  case,  any  two  hosts  in  different  IP  subnets  that  have  direct  ATM 


36 


connectivity  between  them  cannot  talk  to  each  other  without  first  visiting  an  IP  router. 
This  decreases  the  efficiency  of  the  ATM  performance  in  that  network  [Kavak  95]. 

In  order  to  overcome  this  limitation,  the  Routing  Over  Large  Clouds  (ROLC) 
working  group  has  released  a  new  protocol  known  as  the  Next  Hop  Resolution  Protocol 
(NHRP).  NHRP  is  built  on  the  classical  ff  model  over  the  networks  such  as  ATM,  Frame 
Relay,  or  X.25.  These  networks  are  called  as  Non-Broadcast  Multi- Access  (NBMA) 
[Alles  95].  The  goal  is  to  let  a  host  bypass  some  or  all  of  the  IP  routers  on  the  way  by 
establishing  a  direct  connection  through  the  ATM  fabric  [Kavak  95]. 

Simply  the  idea  in  NHRP  is  that  every  NBMA  LIS  in  classic  IP  over  ATM  has  an 
NHRP  Server  (NHS).  These  servers  can  talk  to  each  other  and  keep  track  of  the  other 
members  of  their  subnet.  When  one  host  wants  to  talk  to  another,  NHS  resolves  the  ATM 
address  of  the  destination  if  it  is  in  the  same  subnet,  otherwise  it  communicates  with  other 
NHSs  by  using  IP  packets.  NHRP  finds  the  destination  address  so  that  it  can  be  given  to 
the  source  host.  NHRP  also  has  some  deficiencies.  One  major  problem  is  that  giving  a 
direct  connection  between  source  and  destination  violates  basic  assumptions  in  IP  routing 
[Alles  95].  This  problem  is  particularly  severe  with  respect  to  multicast. 

E.  INTEGRATING  MULTICAST  AND  MBONE  WITH  ATM 

The  Multicast  Backbone  (MBone)  was  started  in  1992.  After  seeing  the 
capabilities  of  MBone  multiparticipant  real-time  audio/video,  other  applications  like 
conferences,  DIS  and  distance  learning  were  conceived.  The  main  problem  for  the  MBone 
is  the  bandwidth  limitation  that  the  Internet  has  today.  The  default  global  video  stream 
bandwidth  is  128  Kbps  which  is  about  1-4  frames  per  second  [Macedonia  95].  Global 
bandwidth  for  MBone  is  500  Kbps.  With  better  application  tools  such  as  vie,  ivs,  and  rat. 
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with  better  data  compression  algorithms  and  with  forward  error  correction,  video  and 
audio  quality  is  getting  better.  Chapter  IV  and  Appendix  B  has  more  information  about 
MBone  and  MBone  tools.  Video  conferencing,  distance  learning  opportunities  with  the 
participation  of  many  educational  establishments,  and  the  capability  of  large-area 
simulations  (which  will  be  described  in  Chapter  VI)  all  encourage  the  trend  to  multicast 
and  use  MBone.  ATM  is  a  possible  way  to  support  the  MBone  with  high-bandwidth  links. 

There  is  no  specific  support  in  the  “classical  IP  over  ATM”  protocol  for  multicast 
[Laubach  94],  since  “classical”  appears  to  be  misleading  euphemism  for  unicast.  There  are 
a  couple  of  solutions  that  have  been  proposed.  Multicast  Address  Resolution  Server 
(MARS)  was  introduced  in  [Grenville  96].  MARS  is  a  kind  of  replacement  of  the  ATM 
ARP  server  (ATM ARP)  that  is  introduced  in  [Laubach  94]. 

MARS  serves  a  cluster,  a  group  of  hosts.  All  end  systems  in  that  cluster  are  set  up 
with  the  ATM  address  of  the  MARS.  When  a  node  wants  to  participate  in  a  multicast 
group,  it  generates  an  Internet  Gateway  Message  Protocol  (IGMP)  report  message  so  that 
all  multicast  routers  on  the  subnet  are  informed.  From  then  on,  all  multicast  requests  go 
through  MARS  if  the  destination  node  in  a  multicast  activity  belongs  to  another  cluster. 

Possible  implementation  algorithms  for  multicast  over  ATM  are  stiU  being 
explored  by  the  Internet  Engineering  Task  Force  (IETF)  working  group.  There  is  no 
standard  for  multicast  over  ATM.  Even  though  there  are  a  few  ATM  switches  of  different 
companies  supporting  proprietary  versions  of  multicast  over  ATM,  they  are  not 
compatible  with  each  other  and  not  compatible  with  multicast  IP.  This  is  big  handicap  for 
researchers  interested  in  multicast  and  ATM. 
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E  ARRANGING  LONG-HAUL  ATM  CONNECTIONS 


ATM  has  been  used  in  LANs  for  a  couple  of  years.  However  long-distance  ATM 
connections  are  essential  if  low-latency  or  high-bandwidth  applications  need  to  be  run 
across  long  distances.  An  innovative  long-distance  ATM  WAN  was  tested  as  part  of  the 
SuperComputing  (SC)  95  conference.  Wdeo  applications  at  different  levels  of  demand 
were  run  in  a  heterogenous  ATM  network  between  San  Diego,  California,  Portland, 
Oregon  and  Albuquerque,  New  Mexico  [Naegle  95].  Even  though  the  compression  rates 
of  the  computers  did  not  allow  using  the  full  speed  of  the  link  (OC-3  at  that  experiment) 
satisfactory  video  quality  was  achieved.  Other  long-distance  applications  (such  as  DIS) 
are  highly  dependent  on  real-time  latency  in  addition  to  bandwidth.  All  communications 
are  limited  to  speed  of  light  beside  the  limitation  of  high  bandwidth.  Light  makes  a  round 
trip  between  west  and  east  coasts  of  U.S.  in  about  30  ms.  In  order  to  meet  human  factors 
requirements  explained  in  Chapter  VI,  it  is  necessary  for  any  round-tiip  message  to  not 
exceed  about  100  ms  to  achieve  interactions  in  a  virtual  environment.  Thus  acceptable 
latencies  coast-to-coast  using  ATM  are  conceivable.  In  summary,  the  variables  in  long 
distance  latency  are  ATM  switching  time,  source/destination  computer  process  time,  and 
light  transit  time  through  fiber.  ATM  switch  process  time  is  getting  better  and  better,  and 
the  average  process  time  today  as  well  as  connection  bandwidth  is  not  a  barrier  to  the  real¬ 
time  use,  even  though  the  ATM  capable  links  are  quite  expensive  and  it  may  take  several 
years  to  have  a  cross-country  ATM  network.  The  most  important  technical  impediment  to 
very  low  latency  appears  to  be  processing  time  at  the  end  hosts. 
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G.  NPS  ATM  LAN  REPORT 


NPS  has  been  involved  in  ATM  since  1995.  ATM  is  used  in  the  NPS  System 
Technology  Lab  (STL)  and  NPS  Computer  Center.  The  first  goal  was  to  establish  LANs  in 
these  two  places,  then  to  connect  them  together  and  finally  to  connect  to  the  outside  world. 

In  the  fibrst  step,  two  SGI  Indy  computers  were  selected  to  install  ATM  Network 
Interface  Cards  (NICs).  In  order  to  prevent  a  routing  loop  in  the  existing  IP  LAN,  Indys 
were  given  a  second  ATM  address,  so  that  any  ATM  cell  would  not  jump  into  IP  network. 
These  two  machines  were  experimented  on  as  peer-to-peer  ATM  links  without  any  switch 
between  them  (Figure  5.6).  This  was  done  by  setting  up  a  PVC  between  the  machines. 


Figure  5.6.  Peer-to-Peer  ATM  Without  Any  Switch 

In  the  second  step,  a  Cisco  A-IOO  ATM  switch  was  put  between  the  two  machines, 
to  support  an  ATM  link  simulating  an  ATM  LAN  configuration  (Figure  5.7). 


Figure  5.7  ATM  LAN  with  One  ATM  Switch 

In  the  third  step,  a  second  Cisco  A- 100  ATM  switch  was  added  into  the  LAN  near 
the  other  switch,  so  that  the  simulation  of  two  different  LANs  was  achieved  (Figure  5.8). 
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Figure  5.8  ATM  LAN  Simulation  by  Using  Two  Nearby  ATM  Switches 


In  the  fourth  step,  STL  was  connected  to  Computer  Center  physically  through  a 
PVC  connection  again.  Hence,  instead  of  simulating  two  different  LANs,  the  system  was 
configured  as  two  physically  separated  LANs  (Figure  5.9). 


Figure  5.9  ATM  LAN  Configuration  With  Two  ATM  Switches  in  Separate  Places 


In  the  last  step,  NPS  was  connected  to  University  of  California  Santa  Cruz  (UCSC) 
through  Monterey  BAY  NET  ATM  PVC  connections  (Figure  5.10). 

The  follow-up  goals  are: 

•  Using  SVCs  inside  the  school  and  between  UCSC  and  the  school 

•  Using  multicast  and  MBone  over  ATM  inside  and  outside  the  school 

•  Adding  security  features  to  ATM  (i.e.,  Kerberos) 

•  Going  across  the  country 

Significant  problems  with  ATM  exist  and  can  be  summarized  as  follows: 

1.  Interoperability  between  switches 

There  is  no  way  to  guarantee  communication  between  switches.  This  was  seen  in 
many  communication  problem  encountered  between  different  proprietary  switches. 
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Switches  have  different  communication  features  and  they  are  not  able  to  communicate 
with  each  other. 


2.  Incompatibility  with  IP 

There  is  no  native  way  to  multicast  with  ATM.  There  is  a  lot  of  effort  going  into 
solving  the  IP  and  multicasting  problems,  but  so  far  no  acceptable  solution  has  been 
found. 

3.  Long-Haul  Connectivity 

Myriad  long-haul  problems  exist.  These  problems  are  especially  difficult  due  to 
the  change  in  the  regulations  concerning  Regional  Bell  Operating  Companies  (RBOC)’s 
being  long-haul  carriers.  This  includes  setup  and  tariff  issues. 

4.  Insufficient  Trained  Expertise 

The  human  engineering  problem  is  currently  almost  insurmountable.  The 
“expertise”  that  exists  in  the  ATM  field  is  minimal  due  to  the  immaturity  of  the 
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technology.  No  one  at  NPS  had  ever  dealt  with  ATM  prior  to  our  purchasing  the  switches. 
All  the  expertise  that  we  had  was  learned  through  trying  to  establish  the  NPS  ATM  LAN. 
Trying  to  get  assistance  is  next  to  impossible  due  to  the  fact  that  so  few  people  have  any 
proficiency  in  ATM. 

5.  Crossover  Lacking 

If  a  connection  is  broken,  there  is  no  standby  connection  waiting  to  immediately 
take  over.  This  scenario  is  heightened  in  the  already  problematic  multicast  situation. 

More  information  about  the  NPS  ATM  LAN  can  be  found  in  [Couitney  96]  and 
[NPS  ATM  LAN]. 

H.  BAYNET  REPORT 

According  to  [Garcia-Luna  95]  the  objectives  of  Monterey  ATM  BAYNET  are: 

♦  A  new  educational  paradigm  (interactive,  exploratory,  current,  distance 
(independent),  and  life-long  learning  opportunities  for  the  21st  century  schools, 
government,  and  industry  of  the  Silicon  Valley  and  Monterey  Bay  region. 

♦  Ubiquitous  access  and  timely  delivery  of  environmental  and  oceanographic 
information  to  users  in  the  various  economic  sectors  of  the  Silicon  Valley  and  the 
Monterey  Bay  region. 

♦  Innovative  information  products  and  services  that  forge  new  linkages  and 
collaborations  between  economic  sectors  and  geographic  regions 

♦  Dynamic  dissemination  mechanisms  for  providers  of  public  information 
products  and  services. 

Two  commonly  used  terms  in  BAYNET  project  are  “teleducation”  and 
“telescience”.  Teleducation  is  equivalent  to  distance  learning.  Telescience  can  be 
described  as  remote  visualization,  and  the  control  of  remote  experiments  and  interactions 
with  remote  scientists. 

BAYNET  is  an  Califorma  Research  and  Education  Network  (CalREN)  project. 
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From  the  point  of  this  thesis,  the  important  accomplishments  can  be  explained  as  follows. 

1.  Distance  Learning  Applications 

Distance  learning  applications  were  utilized  over  ATM  links  between  UCSC  and 
UC  Extension  at  the  first  step  and  between  the  Monterey  Bay  Aquarium  (MBA)  and 
Monterey  Bay  Aquarium  Research  Institute  (MBARI)  at  the  second  step.  A  later  goal  will 
connect  these  links  to  each  other  and  to  other  educational  services. 

2.  Bay  Link  Application 

In  order  to  show  the  Monterey  Bay  submarine  canyon  ecosystem  to  a  larger  world, 
MBA/MBARI  and  the  San  Jose  Technology  Museum  of  Innovation  (SJTMI)  were 
connected  to  each  other  by  ATM  networks.  They  used  proprietary  video  compression 
hardware  and  proprietary  distributed  multimedia  software. 

By  using  the  Bay  Link  capability,  students  and  visitors  at  the  SJTMI  can 
interactively  participate  in  the  exploration  at  the  Monterey  Canyon  with  MBARI 
scientists.  This  event  is  carried  out  in  real  time  with  full  motion  video  from  the  bottom  of 
the  Monterey  Canyon  by  using  a  remotely  operated  underwater  vehicle  and  its  camera. 

This  application  worked  because  the  principals  spent  a  lot  of  money  on  proprietary 
hardware,  software  and  technical  consultants.  Thus  it  is  of  limited  use  to  this  project 
because  it  is  not  open  and  not  IP-compatible. 

I.  REGARDING  ATM  FOR  MBONE-COMPATEBLE  DISTANCE 
LEARNING 

ATM  is  promising  for  faster,  more  tmsted,  higher-bandwidth  networks.  Since  its 
physical  layer  must  be  supported  by  complex  network  connections,  it  will  take  some  time 
to  complete  an  ATM  network  around  the  country  or  around  the  world.  It  will  also  continue 


to  have  reliability  problems  since  it  violates  yet  another  Internet  design  principle  by 
pushing  signaling  complexity  into  the  switches,  rather  than  keeping  complexity  at  the  end 
hosts.  However  ATM  continues  to  improve.  There  have  been  several  experiments  at  long¬ 
distance  ATM.  The  Bay  Area  Gigabit  NETwork  (BAGNET)  covered  the  San  Francisco 
Bay  Area  (explained  in  Chapter  H).  BAYNET  covered  a  real-time  Bay  Link  experiment 
(May  5, 1995,  it  was  the  first  demonstration  of  a  transcontinental  end-to-end  ATM 
application  with  the  participation  of  two  high  schools,  one  in  North  Carolina  and  one  in 
Illinois  [Garcia-Luna  95]).  CANARIE  covered  an  across-the-country  network  in  Canada 
as  well  as  the  I1S1ET96  exhibition  which  covered  several  countries  around  the  world.  There 
are  many  other  experiments  in  Europe,  and  in  Japan.  Unfortunately,  in  each  case  a  great 
deal  of  work  was  required  to  set  up  long-haul  links,  and  circuits  were  permanently  torn 
down  immediately  after  use. 

For  the  time  being,  existing  IP  networks  can  be  included  in  the  ATM  networks  by 
using  inadequate  protocols  like  classical  IP  over  ATM.  There  are  some  problems  in  ATM 
shown  in  Figure  5. 1 1. 

•  Interoperability  between  switches 

•  Incompatibility  with  IP,  especially  IP  multicast 

•  Long-haul  connectivity 

•  Insufficient  trained  expertise 

•  Crossover  lacking 

Figure  5.1 1  Significant  Problems  with  ATM. 

The  importance  of  multicast  in  applications  such  as  simulation,  scientific 
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visualization,  distance  learning,  video  conferencing  and  data  sharing  is  well  understood. 
Efforts  to  improve  ATM  networks  will  not  end  soon.  Hopefully  these  serious  ATM  flaws 
can  be  corrected  and  ATM  wiU  be  useful  for  Internet-compatible  multicast-based  distance 
learning. 

J.  SUMMARY 

ATM  is  a  new  technology  designed  to  meet  high-bandwidth  and  low-latency 
requirements  of  existing  networks  to  support  various  types  of  traffic  such  as  data,  voice 
and  video.  However,  significant  problems  with  ATM  exist.  Interoperability  problem 
between  ATM  switches,  incompatibility  with  IP  multicasting,  long-haul  connectivity 
problem,  insufficient  trained  expertise  and  crossover  lacking  are  the  most  important 
problems.  Because  of  these  problems,  ATM  is  not  ready  for  integrating  with  MBone  and 
multicast  for  affordable  distance  learning  purposes.  When  these  serious  ATM  flaws  are 
corrected,  ATM  may  be  useful  for  Internet-compatible  multicast-based  distance  learning. 
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VI.  DISTRIBUTED  INTERACTIVE  SIMULATION  (DIS)  PROTOCOL 

AND  MBONE 


A.  INTRODUCTION 

This  chapter  explains  the  DIS  protocol  and  its  use.  Section  B  gives  background 
information  on  DIS.  Section  C  introduces  the  features  of  DIS,  problems  and  solutions  to 
some  of  these  problems.  Section  D  explains  the  use  of  DIS  with  MBone,  limitations  and 
future  work. 

B.  BACKGROUND 

Military  warfare  modeling  goes  back  centuries.  It  was  developed  and  became  more 
structured  in  the  19th  and  early  20th  century.  The  Japanese  used  gaming  before  the  attack 
on  Pearl  Harbor,  and  the  U.S.  Navy  War  College  wargamed  possible  Pacific  operations 
before  World  War  n.  In  the  1970’s  simulations  became  more  sophisticated  by  allowing  for 
separate  interactions  between  classes  of  weapons  but  there  was  stiU  no  human  intervention 
in  the  system  [Davis  95]. 

In  the  early  1980’s,  microprocessor  technology  began  to  produce  less  expensive 
computers  and  affordable  local  and  wide-area  networks  became  available  to  connect 
computers.  Eventually  with  these  new  technologies  a  new  era  in  simulators  started.  It 
became  feasible  to  consider  developing  large  networks  of  simulators  that  might  be 
connected  for  operation  in  real  time.  In  1983,  ARPA  developed  the  SIMulator 
NETworking  (SIMNET)  Project.  The  first  conceptual  demonstration  was  conducted  in  late 
1984,  and  the  first  demonstration  involving  real-time,  out-the-window  graphics  was 
conducted  in  late  1985.  The  first  platoon-level  system  having  image  generation 
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capabilities  was  installed  in  1986.  The  first  helicopter  simulators  were  installed  in  1987 
[Mmer95]. 

Since  SIMNET  was  designed  for  Ethernet  technology  and  relied  on  broadcasting, 
it  was  hard  to  extend  fi:om  a  LAN  to  large  distributed  networks.  After  the  Gulf  War  in 
1990,  the  necessity  for  large-scale  simulations  with  as  many  as  100,000  entities  was 
envisioned.  The  inefficiency  of  SIMNET  protocol  for  that  number  of  entities  made 
researchers  look  for  a  more  sophisticated  and  feasible  protocol  for  the  simulators.  By  late 
1992,  the  initial  set  of  Distributed  Interactive  Simulation  (DIS)  standards  was  agreed 
upon.  In  March  1993,  the  first  standards  were  formally  approved  [MiUer  95].  Currently 
DIS  can  support  several  hundred  simultaneous  entities.  Work  continues  to  improve  DIS 
efficiency. 

C.  DIS  PROTOCOL 

1.  Introduction 

The  DIS  Vision  document  [DIS  Steering  Committee  94]  describes  the  domain  of 
interest  as  follows. 

The  primary  mission  of  DIS  is  to  define  an  infrastructure  for  linking  simulations 
of  various  types  at  multiple  locations  to  create  realistic,  complex,  virtual  ‘worlds’ 
for  the  simulation  of  highly  interactive  activities.  This  infrastructure  brings 
together  systems  built  for  separate  proposes,  technologies  from  various  services 
and  permits  them  to  interoperate.  DIS  exercises  are  intended  to  support  a  mixture 
of  virtual  entities  (human-in-the-loop  simulators),  live  entities  (operational 
platforms  and  test  and  evaluation  systems),  and  constmctive  entities  (wargames 
and  other  automated  simulations)  [DIS  Steering  Committee  94]. 

DIS  may  be  defined  as  a  group  of  standards  being  developed  by  the  DoD,  industry 

and  academia  to  provide  a  basis  for  interoperating  many  different  hardware  and  software 

platforms  [Macedonia  95]. 

The  main  areas  for  the  development  of  standards  in  DIS  are  described  below. 
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a.  Protocols  for  Data  Interchange 

Some  of  the  points  in  developing  are  precise  identification  of  data  items,  a 
common  representation  of  data  items.  Protocol  Data  Units  (PDUs)  and  dead-reckoning 
algorithms. 

b.  Communication  Architecture 

Some  of  the  related  areas  are  type  of  addressing  (unicast,  multicast, 
broadcast),  reliability,  detennining  bandwidth  requirements,  constraints,  and  performance 
capabilities. 

c.  Security 

Development  in  security  consists  of  establishment  of  a  security  policy  and 
security  service  performance  requirements,  publication  of  security  guidance  documents, 
and  security  accreditation  guidelines. 

d.  World  Environment  Representation 

Issues  for  achieving  environmental  representation  among  heterogeneous 
simulators,  simulations,  and  range  systems  are  identifying  common  sources  for 
environmental  data,  creating  standards  for  the  representation  of  that  data,  creating 
repository  databases  for  the  collection  and  storage  of  the  common  data. 

e.  Computer  Generated  Forces  (CGF) 

CGFs  replaced  Semi- Automated  Forces  (SAFs),  designed  to  simulate  the 
externally  visible  behavior  of  forces  without  requiring  large  numbers  of  manned 
simulators  and  people  to  operate  them  and  to  provide  exercise  for  supervisory  control  over 
units  that  may  have  many  vehicles  [Hafer  95]. 

Many  aspects  of  the  SIMNET  protocol  such  as  its  general  principles,  terminology 
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and  PDU  formats  have  been  used  also  in  the  DIS  standards  [Macedonia  95].  The  entity 
State  PDU  (ESPDU)  structure  is  shown  in  Figure  6.1.  ESPDUs  can  be  used  for  reporting 
the  change  in  status  of  moving  entities.  All  27  different  PDUs  are  structured  like  ESPDU 
with  fields  and  records  designed  to  transfer  the  different  types  of  information  required  for 
a  common  synthetic  environment.  The  variety  of  PDUs  developed  are  used  for  exchanging 
different  types  of  messages  between  the  entities.  For  instance,  the  ESPDU  provides  the 
means  for  reporting  the  change  in  status  of  moving  platforms.  Other  types  of  PDUs 
provides  related  information  with  their  names,  such  as  Fire,  Detonation,  Collision. 

2.  Networking  Requirements  for  DIS 

a.  Having  Real-Time  Simulations 

According  to  various  studies,  human  users  begin  to  perceive  delay  at  about 
100  ms.  In  DIS  application,  it  is  important  to  have  low  latency  to  achieve  realistic 
real-time  simulations.  For  tightly  coupled  units  (such  as  aircraft  formation)  default  values 
have  been  defined  as  100  ms  where  as  for  aU  other  cases  it  has  been  defined  as  300  ms 
[Pullen  95].  Up  to  five  seconds  is  allowed  for  slower-moving  or  stationary  entities. 
Real-time  requirements  in  a  network  can  be  achieved  by  using  UDP,  but  that  brings  up 
another  requirement  which  is  high  reliability.  Detonation  and  Fire  PDUs  are  required  to  be 
delivered  more  reliably  than  ESPDUs.  Reliability  can  be  provided  by  using  transmission 
control  protocol  (TCP)  but  it  delays  delivery  of  sizable  blocks  of  data  whenever  a  packet  is 
lost,  and  therefore  is  inconsistent  for  real-time  delivery  [Pullen  95]. 
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b.  Multicasting 

Multicasting  is  a  means  of  data  transfer  from  one  host  to  the  other(s)  in 
addition  to  broadcast  and  unicast.  In  multicast,  it  is  possible  to  have  a  capability  of 
one-to-many  and  many-to-many  data  transfer  for  a  special  group  of  hosts  participating  in  a 
session.  In  a  distributed  large-area  network,  multicast  is  a  desirable  feature.  Only  one  copy 
of  a  message  is  sent  to  the  members  of  a  multicast  group,  minimizing  bandwidth 
requirements. 

c.  Security  Issues 

Since  DoD  DIS  applications  have  sensitive  data,  a  means  of  encryption  to 
provide  security  in  the  simulation  wide-area  network  is  paramount. 

A  second  issue  for  security  concerns  multicast.  If  we  want  to  use  multicast 
in  the  network  and  have  several  multicast  groups,  then  we  must  have  key  management 
for  distribution  to  the  groups.  Furthermore,  joining  and  leaving  existing  groups 
dynamically,  participating  in  more  than  one  simulation,  international  simulations,  and 
multi-level  security  are  considered  other  important  management  issues  [Pullen  95]. 

d.  Capacity  of  a  Network 

After  the  Gulf  War  in  1990,  the  necessity  of  having  a  large  number  of 
entities  in  the  simulation  exercises  became  more  important.  If  such  an  exercise  were 
conducted  for  100,000  entities  (which  is  the  goal  of  DoD)  then  we  would  have  at  least  175 
Mbps  on  the  network  [Miller  95].  That  number  could  be  as  high  as  375  Mbps  [Macedonia 
95]  and  this  presents  serious  problems,  because  375  Mbps  of  network  bandwidth  to  each 
computer  participating  in  the  simulation  is  unrealistic  for  an  affordable  system 
[Macedonia  95]. 
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3.  Problems  With  DIS 


a.  Great  Amount  of  Bandwidth  and  Computation  Requirements 

As  mentioned  above,  a  simulation  involving  100,000  entities  requires  a 
bandwidth  of  375  Mbps.  Every  entity  is  tracked  and  updated,  and  maintaining  the  update 
state  is  achieved  by  sending  PDUs  to  all  other  entities  by  the  host  entities.  The  problem 
with  this  scenario  is  that,  if  the  entity  is  moving,  its  position,  velocity,  and  orientation  will 
change  and  the  PDUs  which  has  a  lot  of  other  information  in  them  will  be  broadcast  to  all 
other  entities.  This  redundancy  is  a  very  bandwidth-consuming  process.  It  is  even  a  larger 
problem  if  we  think  about  inherent  network  redundancy  in  broadcasting.  This  is  a 
principle  reason  for  a  bottleneck  in  large-scale  simulation  environment. 

The  DIS  protocol  transmits  acceleration,  velocity  and  position  data 
whenever  a  remote  object  exceeds  a  dead-reckoning  threshold  or  a  5  second  time-out 
period.  Dead-reckoning  algorithms  use  first-  or  second-order  models  to  predict  the  future 
object  location.  Because  the  algorithms  are  highly  real-time  dependent,  the  conversions  in 
updating  process  are  heavily  computational  [Singhal  95]. 

b.  Security 

In  large-scale  distributed  simulation  exercises,  there  are  certainly  some 
security  requirements  and  access  authorizations  for  participants.  They  need  to  exchange 
some  information  with  the  other  participants.  However,  one  encr5q)tion  technology  often 
used  today  (known  as  link  encryption)  encrypts  all  of  the  stream  passing  through  a 
point-to-point  data  link.  Even  though  this  form  is  widely  used,  it  has  security  constraints 
on  the  nodes  because  insecure  intermediate  nodes  cannot  transfer  these  streams  [Pullen 
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95].  The  other  encryption  method,  end-to-end  packet  encryption,  does  not  encrypt  the 
header  of  the  packet.  It  is  more  flexible  since  it  allows  use  of  insecure  intermediate  nodes 
in  the  network  [Russell  91].  However  the  only  end-to-end  encryption  system  approved  for 
military  use  is  bound  to  a  maximum  data  rate  of  T1  link  (~1.5  Mbps)  [Pullen  95]. 

c.  Multiplexing/Demultiplexing  of  Media 

The  current  DIS  protocol  requires  an  application  layer 
multiplexing/demultiplexing  for  real-time  data  (e.g.,  simulation  packets,  audio,  and  video) 
rather  than  the  network  or  transport  layer.  It  is  difficult  to  build  DIS  applications  that  can 
efficiently  use  all  kinds  of  data  such  as  audio  [Macedonia  95]. 

d.  Others 

Some  problems  are  explained  in  [Macedonia  95]  and  can  be  summarized  as 


follows: 

•  For  large,  heterogenous  simulation  networks,  it  is  necessary  to 

have  an  “on-demand”  data  distribution  to  achieve  efficiency.  There  is  no  such 
mechanism  in  DIS. 

•  DIS  does  not  have  any  method  to  communicate  all  the  abstractions  needed  to 
present  a  complete  and  consistent  view  of  reality  (e.g.,  clouds,  weather,  smoke) 

•  Another  problem  is  fidelity.  Every  simulator  in  DIS  applications  is  assumed  to 
be  truthful.  In  a  large-scale  heterogenous  simulation,  the  quality  of  realism  that 
each  simulator  has  affects  the  realism  of  the  exercise  (e.g.  a  highly  realistic 
simulator  cannot  compete  against  a  less  accurate  one). 

4.  Possible  Solutions  to  Problems 

There  are  a  variety  of  ways  to  deal  with  bandwidth  requirements  and  heavy 
computation.  Multicasting  is  the  first  one.  Multicast  minimizes  network  bandwidth.  The 
network  is  not  used  unnecessarily  by  sending  packets  to  every  entity  even  when  unneeded. 
Another  advantage  of  multicast  is  that  it  reduces  the  computation  at  the  entities.  Entities 
take  only  the  information  (PDU)  they  need  because  multicast  can  be  subscribed  or 
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discriminated  against  in  the  network  interface  card  hardware  rather  than  the  application 
layer  software.  Thus  they  do  not  need  to  perform  extra  computations  to  ignore 
unsubscribed  PDUs. 

According  to  [Morrison  95]  there  are  two  approaches  to  deal  with  the  complexity 
of  the  DIS  protocol.  One  is  the  “Newtonian  Pkotocol”  by  the  Defense  Advanced  Research 
Project  Agency  (DARPA).  The  main  idea  is  to  combine  the  many  special-purpose  DIS 
PDUs  (like  the  collision  and  detonation)  into  lesser  numbers  of  PDUs. 

ATM  is  a  promising  approach  for  low-latency,  high-speed  network  connectivity 
required  by  large-scale  wide-area  distributed  simulations.  We  have  discussed  ATM  in 
Chapter  V.  Multicast  IP  over  ATM  is  still  a  research  area.  There  are  some  implementations 
of  multicast  IP  over  ATM,  but  for  now,  they  lack  the  capability  for  working  with  different 
brands  of  ATM  switches. 

Instead  of  using  the  dead-reckoning  algorithm  that  is  used  by  DIS  now,  an 
algorithm  like  Position  History-Based  protocol  described  in  [Singhal  95]  may  be  more 
efficient.  Some  of  the  advantages  mentioned  in  the  reference  can  be  summarized  as 
follows: 

•  It  tracks  remote  objects  more  smoothly. 

•  At  wider  thresholds,  it  smooths  the  motion,  while  DIS  protocol  exaggerates  it. 

•  By  using  timestamps  to  synchronize  the  remote  tracking  at  receiving  hosts,  it  is 
effective  in  addressing  latency  and  jitter  issues  in  real-time  visualization  systems. 

•  It  transmits  a  total  of  386  bits,  where  as  DIS  protocol  transmits  a  total  of  672 
bits.  The  history-based  protocol  can  transmit  1.75  times  as  often  as  DIS  and  still 
reduce  bandwidth. 

•  The  lighter  packet  load  is  important  for  supporting  large  virtual  environments 
containing  large  number  of  participants. 

•  There  is  no  additional  computational  overhead  on  sending  or  receiving  hosts, 
and  the  algorithm  can  actually  reduce  computational  load. 

For  key  management,  end-to-end  encryption  and  bandwidth  limitation,  there  is  a 
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project  mentioned  in  [Pullen  95].  As  indicated  above,  the  only  end-to-end  encryption 
system  currently  approved  for  military  use  is  good  only  to  a  maximum  data  rate  of  T1 
level.  When  National  Security  Agency  (NSA)  fields  a  new  end-to-end  encryptor  called 
“FASTLANE”  which  will  support  ATM,  it  is  expected  to  provide  the  data  rates  required 
by  DIS.  This  encryptor  standard  also  has  some  advanced  features  such  as  “key  agile,”  the 
ability  to  apply  multiple  encryption  keys  dynamically,  and  will  achieve  some  key 
management  goals.  Multicast  on  ATM  by  using  FASTLANE  is  a  future  research  area. 

D.  DIS  AND  MBONE 

As  shown  in  Chapter  VI,  the  MBone  enables  the  distribution  of  IP  multicast  over 
the  Internet.  Since  researchers  have  been  looking  for  opportunities  to  provide  multicast 
capability  to  DIS  applications,  the  MBone  is  an  excellent  candidate  for  long-haul 
connectivity. 

NPSNET  was  the  fixst  DIS  application  to  use  IP  multicast  and  also  to  be  tested 
experimentally  over  the  MBone.  The  NPSNET-IV  networked  virtual  environment  was 
developed  at  the  Computer  Science  Department  of  the  Naval  Postgraduate  School  (NPS) 
in  Monterey  California.  By  having  IP  multicast  capability,  sites  that  participate  in 
distributed  simulations  can  be  connected  directly  via  MBone. 

After  SIGGRAPH  93,  the  multicast  version  of  NPSNET-IV  was  completed.  The 
first  communication  was  established  between  SRI  in  Menlo  Park  and  NPS.  That  event 
presented  an  important  challenge  for  interactive  simulation.  Despite  a  hostile  network 
environment,  NPSNET-IV  had  a  small  amount  of  perceptual  latency.  A  more  detailed 
explanation  can  be  found  in  [Macedonia  95]. 

These  MBone  experiments  were  important  because  they  showed  the  use  of 
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multicast  in  DIS  applications.  However,  the  number  of  the  participants  were  far  from  the 
DoD  goal.  T1  lines  were  used  to  connect  sites,  so  the  bandwidth  was  limited.  There  was  a 
perceptual  latency  which  can  make  the  simulation  performance  far  from  real-time 
requirements.  Dead-reckoning  algorithms  usually  can  reduce  this  perceptual  latency  to 
acceptable  level. 

Researchers  continue  looking  for  better  methods  for  instrumenting  3D  simulations. 
Some  new  ideas  are  explained  in  [Brutzman  96].  We  believe  it  is  physically  achievable  to 
have  Large-Scale  Virtual  Environments  (LSVEs)  across  the  country  without  simulator 
sickness  for  fully  represented  and  fully  immersed  humans.  There  are  two  fundamental 
steps  needed  to  permit  the  transition  to  building  useful  LSVEs:  the  Cyberspace  Backbone 
(CBone)  and  Virtual  Reality  Transfer  Protocol  (vrtp). 

The  network  proposed  for  the  CBone  is  a  combination  of  the  National  Transparent 
Optical  Network  (NTON)  and  other  extensions  [Brutzman  96].  By  having  a  predictable 
high-speed  network  with  guaranteed  services,  we  can  reduce  the  transmission  delays 
across  the  network  and  perform  repeatable  experiments  to  optimize  cross-network 
performance. 

The  second  step  is  vrtp.  According  to  Brutzman: 

“vrtp  is  to  be  the  applications  layer  protocol  used  for  communicating  state 

information  among  the  various  participants  in  internetworked  LSVEs” 

[Brutzman  95]. 

We  intend  to  use  the  Virtual  Reality  Markup  Language  (VRML),  a  standard 
language  for  describing  interactive  3-D  objects  and  worlds  delivered  across  the  Internet 
[Carey  96].  For  the  high-bandwidth  and  low  latency  requirements  of  virtual  environments, 
many  of  the  client-server  design  assumptions  of  the  Hypertext  Transfer  Protocol  (http)  are 
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no  longer  valid,  vrtp  is  needed  to  take  advantage  of  available  transport  layer  functionality, 
vrq)  will  add  the  latency- tolerant  real-time  behaviors  functionality  (e.g.,  audio/video 
streaming  and  DlS-hke  behaviors)  to  client-server  capabilities.  Details  about  CBone  and 
vrQ)  can  be  found  in  [Brutzman  96]. 

E.  SUMMARY 

This  chapter  describes  the  DIS  protocol,  problems  with  DIS,  and  some  possible 
solutions  for  those  problems.  DIS  is  an  important  demonstration  of  the  possible  ways  of 
using  virtual  environment  in  networks.  DIS  concepts  make  possible  the  use  of  the 
Internet-based  distributed  simulations  for  purposes  such  as  distance  learning.  The 
algorithms  are  getting  better,  the  connections  are  getting  faster  and  larger.  3D  graphics  are 
becoming  more  accessible  by  using  VRML.  Ongoing  research  into  protocols  such  as  vrtp, 
3D  graphics  and  distributed  simulations  hold  further  promise  for  Internet-based  distance 
learning. 
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Vn.  EXPERIMENTAL  RESULTS 


A.  INTRODUCTION 

Requirements,  necessities  and  motivations  on  using  MBone  for  distance  learning 
are  in  Chapter  IV.  This  chapter  covers  experiments  carried  out  at  NFS  in  which  the  author 
participated.  Section  B  is  about  the  MBone/Web  classroom,  explaining  the  issues  that 
must  be  taken  care  of  in  the  planning  and  implementation  phases  of  the  classroom 
experiments.  Section  C  covers  the  AUV  96  Conference  held  by  NFS  between  2-6  June 
1996  and  shows  the  difference  between  a  conference  hall  configuration  and  an  MBone 
classroom,  and  gives  important  steps  to  manage  an  MBone  session  in  a  conference  hall. 
Section  D  covers  the  same  topics  for  the  Web  Content  and  Access  workshop  that  was  held 
on  23  and  26  August  1996  in  the  Mechanical  Engineering  Auditorium  at  NFS. 

B.  MBONE  CLASSROOM 

1.  Goals 

The  goals  of  building  an  MBone/Web  classroom  can  be  listed  as  follows: 

♦  Using  multicast  transmission  method  over  the  existing  Internet,  so  that  a  large 
number  of  people  and  schools  can  use  it  with  no  extra  cost. 

♦  Froviding  a  valuable  reference  source.  World  Wide  Web  (Web),  for  the 
instructors  and  end  users. 

♦  Froviding  a  distance  learning  opportunity  for  overseas  military  shore  based 
stations  for  the  unclassified  classes.  It  may  be  used  even  in  naval  ships,  after 
satellite  communication  came  down  to  the  real  world  with  a  convenient  price/ 
performance  ratio. 

♦  While  addressing  the  issues  above,  keeping  the  cost  at  minimum,  at  least  at  an 
affordable  level  for  all  schools. 

♦  Motivating  follow-up  researchers,  and  providing  a  reference  for  schools  that 
wants  to  use  this  kind  of  a  classroom. 
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2.  Hardware 


It  is  helpful  to  plan  hardware  requirements  by  asking  questions  about  the  use  of  the 
chosen  classroom.  Answers  to  these  questions  help  produce  requirements  for  the 
classroom.  For  the  MBoneAVeb  classroom  at  NFS,  questions  and  answers  are  as  follows: 
•  How  big  is  the  classroom? 

The  classroom  is  a  medium- sized  classroom,  originally  configured  as  shown  in 
Figure  7.1. 


•  What  kind  of  equipment  is  there  in  the  classroom? 

As  in  most  classrooms,  the  MBone/Web  classroom  in  NFS  had  one  overhead 
projector  and  one  projection  screen. 
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•  What  are  the  network  and  power  connections  in  the  classroom? 

The  classroom  had  one  Ethernet  connection  to  the  131.120.63.X  subnet  which 
already  is  on  the  MBone.  In  almost  all  classrooms  there  are  enough  power  outlets  for  some 
equipment.  Since  more  electrical  equipment  than  regular  classrooms  is  used  for  distance 
learning,  two  power  strips  are  necessary  to  provide  power  inside  the  classroom 
(Figure  7.2). 
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Figure  7.2  Power  and  Network  Conditions  of  the  Classroom 


•  What  are  the  light  conditions  in  the  classroom? 

The  classroom  had  regular  ceiling  fluorescent  lights  (Figure  7.3),  windows  at  the 
back  side  with  dark  colored  curtains.  The  problem  with  these  light  conditions  is  that  while 
the  instructor  is  giving  a  lecture,  the  lights  must  be  turned  off  to  give  students  the 
opportunity  of  seeing  slides  or  video  projection.  But  at  the  same  time,  there  must  be 
enough  light  source  so  that  far-end  students  can  see  the  lecture  classroom  from  the  MBone 
session  and  near-end  students  can  read  or  write  what  they  have  in  front  of  them  at  the 
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desks.  Thus  lighting  control  must  be  improved.  A  new  installation  of  directed  lights  on 
each  wall  (as  shown  in  Figure  7.4)  might  provide  better  lighting  conditions.  However  this 
is  a  major  modification.  Instead,  rewiring  the  switches  for  the  existing  lights  was  required 
so  that  lights  at  the  back  and  lights  at  the  front  of  the  classroom  could  be  controlled 
independently  (Figure  7.5).  When  there  is  a  session  the  rear  lights  are  turned  on,  hence 
there  is  just  enough  light  source  for  both  near-end  and  far-end  students.  This  solution 
works  well.  Figure  7.6  shows  the  back  lights  in  the  classroom. 


Figure  7.3  Original  Ceiling  Lights  of  the  Classroom-only  two  banks  had 
separate  switches 


Figure  7.4  One  Idea  for  Extra  Lights.  Lights  Over  Trails  on  the  Wall 
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Figure  7.5  Two  Fluorescent  at  the  Back  are  Controlled  Separately 


Figure  7.6.  The  Back  Lights  in  the  Classroom  are  Turned  on  Separately 
and  All  Four  Banks  are  Now  Independent 

•  What  may  an  instructor  or  a  student  want  in  the  classroom  for  education 
purposes? 

An  instructor  may  want  to  have: 

•  An  overhead  for  slide  presentations, 

•  A  computer  connected  to  the  Internet, 


•  An  overhead  and  a  presenter  to  show  students  to  reflect  the  computer  monitor  to 
the  screen, 

•  At  least  one  or  two  projection  screens  for  overheads  for  more  flexibility, 

•  One  VCR  to  play  video  tapes, 

•  One  video  projector  to  reflect  the  picture  coming  from  the  VCR  to  another 
projection  screen  or  a  light-color  wall,  as  it  was  done  in  NFS, 

•  A  TV  monitor  to  watch  far-end  classroom. 

This  last  item  forces  the  limits  of  MBone  classroom  design,  since  most  of  the 
computers  do  not  have  a  video  output  on  them.  In  most  cases,  the  instructor  may  have  to 
use  a  computer  monitor  to  follow  or  to  answer  far-end  students  even  though  it  is  not  the 
most  convenient  way.  Video  output  cards  are  commercially  available  at  additional 
expense. 

A  student  may  want  to  have  the  following  items  in  addition  to  what  the  instructor 
may  want; 

•  A  TV  monitor  as  a  second  source  for  watching  video  tapes,  the  monitor  also 
helps  greatly  as  the  sound  system  of  the  classroom.  In  the  MBone  classroom, 
either  an  audio  mixer  or  a  sound  system  were  used,  since  speakers  of  monitor 
were  enough  to  hear  video  tape  sound  comfortably  in  the  whole  classroom. 

•  A  microphone  that  is  put  on  by  instructor.  Far-end  students  need  to  hear  the 
instmctor  easily,  so  a  wireless  mike  attached  to  the  instructor  was  used. 

•  A  computer  to  follow  Web  and  MBone.  Even  though  it  might  be  useful,  it  would 
be  highly  expensive,  and  as  far  as  this  thesis  was  concerned  it  was  out  of  question. 

3.  Software 

Software  used  in  the  MBone/Web  classroom  consists  of  a  Web  browser  (such  as 
Netscape  Navigator,  NCSA  Mosaic  etc.)  and  public-domain  MBone  tools. 

Web  browsers  are  more  or  less  the  same,  but  preferably  it  should  have  Java  and  3D 
capability.  Many  of  the  sites  in  the  Web  are  using  Java  and  VRML  3D  browsers  so  if  an 
old  version  of  browser  is  chosen,  it  may  not  necessarily  give  the  anticipated  picture  when 
that  site  is  opened. 

MBone  tools  are  also  upgraded  frequently.  New  versions  of  video  tools,  (such  as 
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vie,  nv)  audio  tools,  (such  as  rat,  vat)  and  session  directories  (such  as  sdr,  sd)  all  must  be 
installed  on  the  network.  In  a  classroom  connected  to  a  subnet  in  the  school,  there  is  not 
much  to  do  with  a  single  particular  computer  since  they  are  available  on  a  network  basis. 
System  administrators  must  be  warned  when  a  new  version  of  these  tools  comes  up,  so 
that  they  can  upgrade  whole  network. 

4.  Topology 

In  order  to  meet  most  of  the  requirements  mentioned  above,  the  following 
equipment  was  provided  either  from  the  NFS  AudioA'ideo  department  or  from  the  System 
Technology  Lab  (STL): 

•  SGI  Indy  workstation  with  a  Presenter  overhead  projector  monitor 

•  A  TV  monitor 

•  A  VCR 

•  A  video  projector 

•  A  projection  screen 

•  A  video  camera 

•  A  wireless  microphone 

The  workstation  needs  to  be  near  the  instructor  for  easy  use.  The  TV  monitor 
should  face  the  students.  Two  overheads  projectors  (one  for  slides  and  one  for  computer 
presenter)  should  be  close  to  each  other  so  that  instructor  can  reach  them  without  moving 
too  much.  Two  projection  screens  are  needed  depending  on  locations  of  overheads.  The 
video  camera  should  be  in  a  place  so  that  it  can  cover  as  large  a  picture  as  it  can  and  be 
operated  by  a  nearby  person  when  necessary.  The  VCR  and  video  projector  should  be 
located  in  a  place  where  anybody  in  the  classroom  can  watch  the  tape  and  not  obscure  the 
picture  since  the  instructor  can  not  do  all  of  these  things  by  his/herself. 

Taking  these  factors  into  account,  the  MBone/Web  classroom  was  configured  as 
shown  in  Figure  7.7.  This  configuration  has  been  tested  for  six  months  and  has  worked 
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fine,  meeting  the  goals  of  this  thesis.  A  complete  reference  on  configuration  and  building 
the  MBone  classroom  can  be  found  in  Appendix  E. 


Figure  7.7  Hardware  Configuration  of  the  Classroom 


The  instructor  can  use  the  blackboard,  use  transparencies,  show  slides  or  play 
video  tape,  as  well  as  showing  a  Web  site.  The  students  at  the  near  end  can  watch  the  video 
tape  either  from  the  monitor  or  on  the  wall  (a  cheap  but  useful  screen),  while  far-end 
students  can  watch  them  through  MBone  playing  either  fi-om  a  TV  monitor,  a  desktop 
computer,  or  a  projection  depending  on  the  configuration  they  have. 

5.  Results 

The  MBone/Web  classroom  is  one  of  the  first  experiments  in  this  area.  The  author 
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achieved  a  certain  level  of  success  with  this  experiment.  Some  of  the  classes  were  carried 
out  between  California  State  University  Monterey  Bay  (CSUMB).  Web  was  combined  in 
the  classes  with  MBone.  Video  recording  opportunity  was  also  used  to  record  some  of  the 
lectures  and  presentations  for  later  playing  through  the  MBone.  The  MBone/Web 
classroom  is  still  used  by  instructors  since  it  has  been  perceived  as  useful.  Practice  has 
shown  that  use  of  this  equipment  is  easy  and  simple,  which  prevents  the  technology  from 
obscuring  instruction.  Further  use  will  likely  improve  it  more. 

C.  AUV  96  CONFERENCE 

1.  Goals 

Multicasting  the  AUV  96  Conference  through  the  MBone  was  a  great  opportunity 
for  NPS  students  to  use  MBone.  After  the  experience  gained  with  the  MBoneAVeb 
classroom,  the  author  used  this  conference  as  a  second  step  in  networked  distance 
learning. 

Equipment  from  the  MBone/Web  classroom  was  moved  to  the  conference  location 
two  days  in  advance.  The  computer  network  was  reconfigured.  Since  this  was  an 
important  MBone  event,  lots  of  attention  was  paid  to  planning.  Personnel  management 
was  especially  important  since  an  instructor  and  an  assistant  student  are  not  enough  to 
carry  out  a  session  as  may  happen  in  the  MBone  classroom. 

Considering  the  secondary  goals  above,  the  ultimate  goals  may  be  explained  as: 

•  To  be  able  to  manage  larger  events,  such  as  conferences,  exhibits,  seminars, 
multicast  properly  by  using  the  equipment  belong  to  the  school,  and  school 
workers  like  students  and  system  administrators. 

•  To  prepare  a  reference  for  the  similar  events  for  future  use  both  by  the  use  of 
NPS  and  other  educational  institutions. 
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2.  Hardware 


In  hardware  planning,  similar  questions  to  those  for  a  classroom  and  answers  can 
be  helpful  in  obtaining  the  requirements.  These  are: 

♦  How  big  is  the  conference  room? 

Two  different  rooms  were  used  in  the  conference.  Usually  the  small  room  had 
better  video  and  audio  recording  conditions.  In  large  halls,  having  a  satisfactory  level  of 
audio  is  much  more  difficult.  Even  though  house  sound  system  was  used  in  the  conference 
room,  there  were  not  enough  microphones  for  the  audience  so  their  questions  sometimes 
could  not  be  heard  by  the  far  end  audiences.  A  solution  to  this  problem  might  be  using  a 
wireless  mike  and  hand  it  to  the  person  who  asked  a  question.  However  this  lengthens  the 
time  for  questions  so  instead  another  microphone  was  provided  to  the  audience.  Constant 
attention  to  the  volume  of  the  sound  system  is  essential.  In  general,  audio  is  harder  to  do 
properly  than  video. 

♦  What  are  the  light  conditions  in  the  conference  room? 

Light  conditions  are  usually  not  a  problem  in  conferences.  Light  controls  were 
excellent.  When  the  speaker  wants  to  show  a  video  tape  or  slides,  lights  are  diminished  by 
an  assistant  so  that  the  person  behind  the  video  camera  can  take  the  best  picture  possible. 

♦  What  are  the  network  and  power  connections  in  the  conference  room? 

Power  connections  are  not  a  problem  in  conference  rooms  since  they  are  designed 

to  support  many  power  requirements.  Network  connectivity,  on  the  other  hand,  was  the 
biggest  problem  in  the  conference.  There  was  no  built-in  network  connection  at  the  hotel. 
The  best  solution  to  that  problem  was  using  two  wireless  (Airlan)  network  bridges.  These 
bridges  were  regular  386  PC  computer  with  radio  connections  on  bridging  software. 
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Directed  antennas  were  connected  to  the  bridges  so  that  when  pointed  at  each  other,  they 
can  receive/transmit  packets  through  the  air.  Cellular  phones  were  used  during  long¬ 
distance  setup  to  align  antennas  properly. 

After  establishing  the  network  connection  between  the  conference  room  and  the 
school,  the  remaining  task  was  to  drop  Ethernet  cable  from  the  rooftop  Ethernet  bridge 
down  to  the  conference  room,  and  then  to  connect  the  computers  to  that  Ethernet  cable. 

•  What  kind  of  backup  equipment  is  necessary? 

Since  conferences  are  usually  global  on  the  MBone,  backups  must  be  provided  to 
carry  on  multicasting  in  every  situation.  In  this  event,  one  other  workstation  with  MBone 
tools  was  available  which  also  provided  network  monitoring  capabilities.  An 
Unintermptable  Power  Supply  (UPS)  was  also  used  to  protect  expensive  equipment. 

•  What  kind  of  equipment  can  the  conference  center  support? 

Conference  centers  usually  can  help  with  the  electrical,  audio,  and  lightning 

related  problems.  A  planning  session  before  the  conference  is  very  helpful. 

•  What  are  the  plans  for  recording  the  conference? 

It  had  to  be  decided  how  many  cameras  are  needed,  e.g.,  a  single  camera  for  slides, 
audience  and  speakers,  or  separate  cameras  for  each  of  them.  The  final  lineup  has  to 
answer  many  questions.  How  do  you  take  video  tapes  played  by  speakers,  e.g.,  direct 
connection  between  a  VCR  and  the  computer,  or  just  shooting  TV  monitor  by  a  video 
camera?  What  kind  of  equipment  is  necessary  for  the  cameramen,  e.g.,  a  TV  monitor  just 
to  see  what  they  are  recording,  since  it  is  usually  too  tiring  to  look  through  a  small  CRT 
screen  on  the  video  camera  for  hours?  We  tried  many  of  these  possibilities.  Most  worked 
and  only  varied  in  convenience. 
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3.  Software 


Software  requirements  are  not  different  than  for  any  other  MBone  experiments. 
This  time,  instead  of  using  a  network  to  which  the  computers  are  already  connected,  a  new 
network  environment  was  used.  So  MBone  tools  and  network  monitoring  tools  must  be 
installed  locally  on  the  computers  used  in  the  conference. 

4.  Topology 

Combining  the  hardware  and  the  software  requirements  above,  and  checking  with 
the  hotel  engineers  led  us  to  build  the  network  configuration  in  Figure  7.8.  This 
configuration  actually  belongs  to  the  main  conference  center.  Even  though  there  is  a  size 
difference  between  the  two  conference  rooms,  the  configurations  were  nearly  the  same. 


Figure  7.8  Hardware  Configuration  of  AUV  96  Conference  Room 

The  PC  in  this  figure  was  used  only  to  demonstrate  PC  MBone  tools,  to  store 
digital  camera  pictures  and  prepare  them  for  the  home  page  about  the  conference,  and  to 
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make  ftp/telnet  connections.  Events  could  be  written  in  html  concurrendy  while  the 
conference  was  going  on,  by  using  that  PC  and  Web  connection.  More  details  about  the 
preparation  and  the  configuration  phases  can  be  found  in  Appendix  E  Computer  layout  in 
the  conference  is  shown  in  Figure  7.9. 


Figure  7.9.  Workstation,  PC,  TV  Monitor  and  VCR  Configuration. 

5.  Results 

The  AUV  96  Conference  let  NPS  and  the  author  gain  another  challenging 
experience  about  MB  one  multicast,  conference  management  and  configuration  for 
MB  one.  Documenting  this  event  hopefully  allows  successive  researchers  to  improve 
quality  by  allowing  them  to  start  firom  an  improved  knowledge  level. 

This  conference  was  an  opportunity  of  getting  better  picture  quality  from  the 
MBone,  a  more  flexible  configuration  planning  knowledge,  and  a  more  realistic 
requirements  analysis  for  these  kinds  of  events  in  the  future.  Figure  7.10  gives  a  general 
appearance  of  the  speaker  at  the  conference.  Figure  7.11  shows  the  picture  quality  in 
MBone.  This  picture  was  taken  by  a  snapshot  of  the  MBone  video  tool  (vie)  during  the 
conference.  As  a  comparison.  Figure  7. 12  shows  a  picture  taken  by  a  digital  camera  during 
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Figure  7.10.  A  General  Appearance  from  the  Conference. 


Figure  7. 1 1 .  An  Exanriple  of  Video  Quality  of  MBone  Tools. 

D.  MONTEREY  BAY  WEB  CONTENT  AND  ACCESS  WORKSHOP 

1.  Goals 

The  primary  goal  for  this  workshop  was  to  test  a  small  auditorium  environment  for 


MBone  distance  learning.  One  reason  for  this  experiment  is  to  prepare  a  reference  for  the 
follow-up  MBone  users  of  this  auditorium.  Another  reason  was  to  experiment  using 


MB  one  in  a  different  environment.  Unlike  the  conference  in  a  hotel,  we  have  security  at 


the  school  auditorium.  Another  reason  was  to  experiment  in  digital  video/audio  recording 
and  storage  [Tiddy  96].  This  is  one  of  the  first  times  that  digital  recording  was  done 
through  MB  one.  Recording  is  especially  important  to  enable  any  Internet  site  to  record 
and  play  sessions  at  any  time.  More  detailed  information  about  digital  recording  can  be 
found  in  [Tiddy,  96]. 


Figure  7.12.  Author  Monitoring  Conference  Multicast. 

2.  Hardware 

Using  the  same  questions  as  we  did  in  the  previous  sections  to  develop 
requirements: 

•  How  big  is  the  auditorium? 

NFS  Mechanical  Engineering  Auditorium  has  a  capacity  of  1 10  people.  Even 
though  the  auditorium  is  not  small,  acoustics  are  excellent  throughout.  The  auditorium  is 
shown  in  Figure  7.13. 

•  What  are  the  light  conditions  in  the  conference  room? 

Light  conditions  were  good  in  general.  Lights  could  be  controlled  both  from  the 
control  room  and  from  inside  the  auditorium.  The  problem  with  the  lights  was  that  there 
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was  not  enough  directed  lights  for  the  speakers.  So,  when  the  lights  were  dimmed  for 
better  view  of  the  projection,  the  picture  of  the  speaker  taken  by  the  video  camera  was 
almost  dark.  In  the  workshop,  we  tried  to  compensate  for  poor  lighting  design  by  changing 
the  levels  of  the  lights.  This  problem  needs  to  be  corrected. 

*  What  are  the  network  and  power  structure  in  the  auditorium? 

There  was  one  thin  Ethernet  connection  in  the  control  booth,  and  one  in  the 
auditorium  on  the  stage.  New  IP  numbers  were  obtained  from  the  ME  department  system 
administrator.  So,  we  did  not  have  any  network  connection  difficulty  during  the  workshop. 
Power,  on  the  other  hand,  was  a  problem.  Even  though  there  were  enough  outlets  in  the 
control  booth,  there  were  not  many  inside  the  auditorium.  With  two  power  strips  in  a 
single  outlet,  the  powerstrip’s  circuit  breaker  tripped  and  shut  down  a  couple  of  times.  We 
corrected  this  problem  by  changing  one  of  the  power  strips  to  another  outlet  on  the  wall  at 
the  site  of  the  auditorium.  Power  outlets  in  the  middle  section  of  the  auditorium  (where 
most  of  the  equipment  was  used)  were  not  rated  high  enough  to  give  the  power  needed. 
Another  problem  was  that  there  was  no  way  to  pull  cable  between  the  auditorium  and  the 
control  booth,  other  than  by  pulling  the  cables  under  the  doors  which  was  not  a  proper 
way.  Therefore  we  couldn’t  put  the  video  camera  inside  the  auditorium.  Instead,  we 
located  it  in  the  control  booth.  In  this  case  we  had  to  record  behind  the  glass  window  of  the 
control  booth.  Sometimes  the  light  reflection  on  the  glass  was  recorded  unintentionally. 

•  What  kind  of  backup  equipment  is  necessary? 

An  extra  workstation  and  an  Uninterruptable  Power  Supply  (UPS)  is  necessary  as 
backup  equipment. 
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Figure  7.13.  NPS  Mechanical  Engineering  Auditorium  Amphitheater 


♦  WhM  are  the  plans  for  recording  the  conference? 

We  used  a  single  video  camera  located  in  the  control  booth.  Recording  from  the 
booth  has  two  problems.  There  was  a  window  and  we  had  to  take  picture  through  that 
glass  window.  Sometimes,  the  monitor  screen’s  reflection  or  light  from  outside  the  booth 
could  appear  on  the  video.  The  second  problem  is  an  inability  to  videotape  audience 
participations.  Camera  operators  had  to  be  careful  to  deal  with  this  problem.  Since  there 
was  no  house  sound  system  in  the  auditorium,  a  major  flaw  in  the  design  of  the 
auditorium,  we  used  two  wireless  microphones.  One  was  attached  to  the  speaker,  and  the 
other  one  was  a  hand  microphone  passed  to  audience  members  who  wanted  to  ask  a 
question  or  speak.  Since  two  microphones  on  the  same  channel  interfered  each  other,  we 
separated  microphone  channels,  and  selected  the  active  microphone  by  changing  the 
channel  number  on  the  receiver  unit  manually.  This  is  not  the  proper  way  of  controlling 
audio,  since  there  was  some  latency.  Latency  caused  pauses  in  the  sound  multicasted 
through  the  MBone.  A  proper  mixed  solution  is  needed. 

3.  Software 

MBone  tools  and  network  monitoring  tools  must  be  installed  locally  on  the 
computers  used  in  the  auditorium. 

4.  Topology 

The  configuration  of  the  auditorium  for  the  workshop  is  shown  in  Figure  7. 14.  The 
VCR  and  the  projector  were  located  in  the  second  row.  The  reason  for  this  is  that,  when 
the  projector  was  on  the  stage  the  picture  on  the  screen  was  very  small. 
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Figure  7.14.  Configuration  of  the  Auditorium  and  the  Control  Booth 


When  the  projector  was  in  the  back  of  the  auditorium,  a  cabling  problem  occurred 
between  the  VCR  and  the  projector.  We  could  not  put  the  VCR  together  with  the  projector 
at  the  back  of  the  auditorium,  since  the  speakers  would  not  be  able  to  use  the  VCR. 
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Improved  auditorium  sound  design  might  fix  this  problem. 

5.  Results 

Web  Content  and  Access  Workshop  was  another  experiment  for  using  MBone  in 
distance  learning.  The  primary  point  in  this  event  was  to  test  digital  recording.  The  most 
important  problem  we  encountered  during  the  workshop  was  the  audio  problem.  Since 
there  was  no  house  sound  system  in  the  auditorium  (which  is  unusual)  we  had  to  use  two 
wireless  microphones.  Because  they  interfered  with  each  other  when  they  were  on  the 
same  channel,  we  used  two  different  channels.  As  a  consequence,  when  we  switched  the 
channels  between  the  speaker  mike  and  audience  mike,  there  were  unnecessary  pauses  in 
the  multicast.  When  the  speaker  and  the  audience  talked  on  a  subject,  switching  the 
channels  back  and  forth  decreased  the  audio  quality  of  the  multicast.  This  is  an  important 
problem  to  be  corrected.  Documentation  of  this  event  will  allow  more  professional  use  of 
the  auditorium  in  the  future  for  distance  learning. 

E.  SUMMARY 

This  chapter  covered  the  experiments  on  using  MBone  for  distance  learning 
purposes.  Section  B  documented  the  MBoneAVeb  classroom,  explaining  the  issues  that 
should  be  taken  into  account  in  the  planning  and  implementation  phases  of  the  classroom 
experiments.  Section  C  covered  the  AUV  96  Conference  held  by  NFS  between  2-6  June 
1996  describing  the  difference  between  a  conference  hall  configuration  and  an  MBone 
classroom,  and  providing  important  steps  to  manage  an  MBone  session  in  a  conference 
and  configuration  of  a  conference  hall.  Section  D  examined  the  same  issues  for  the  Web 
Content  and  Access  workshop  that  was  held  on  23  and  26  August  1996  in  Mechanical 
Engineering  Auditorium  at  NFS. 
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VIII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

There  are  two  results  of  this  study.  One  is  that  MBone  can  be  used  for  distance 
learning  purposes  successfully  despite  today’s  limited  (128  Kbps)  bandwidth  reserved  for 
MBone.  This  has  been  demonstrated  by  the  MBone  classroom,  AUV  96  conference  and 
the  Monterey  Bay  Web  Content  and  Access  Workshop.  The  quality  of  the  MBone  sessions 
are  nearly  at  the  same  level  with  proprietary  commercial  distance  learning  systems. 
Certainly,  there  is  more  work  needed  to  achieve  fuU-motion  video  with  MBone. 
Nevertheless,  we  can  say  that  MBone  can  be  used  for  distance  learning  purposes  today 
and  tomorrow. 

The  other  result  is  that  an  MBone  classroom  costs  half  as  much  as  a  Video 
Teleconferencing  (VTC)  room  if  a  workstation  is  used,  and  costs  one  fifth  as  much  as  a 
VTC  room  if  a  PC  is  used.  This  price  comparison  may  become  even  more  favorable  when 
considering  that  schools  have  most  of  the  equipment  needed  for  MBone  already  in  their 
inventory.  In  such  cases  the  cost  will  be  even  less.  Hence,  most  schools  can  afford  distance 
learning  even  though  they  can’t  afford  VTC  rooms.  Appendix  G  provides  price 
comparisons. 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

Future  improvements  on  use  of  3D  graphics,  high-bandwidth  networks,  such  as 
ATM,  will  be  beneficial  to  over  distance  learning.  3D  graphics  has  already  been  included 
in  World  Wide  Web.  Real-time  virtual  environments  using  MBone  will  be  another  way  of 
utilizing  MBone.  NPSNET  shows  the  path  for  doing  this.  So  instead  of  multicasting 
video/audio  signal,  PDUs  will  travel  through  the  MBone  and  players  will  be  in  the  same 
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virtual  environment  either  for  a  simulation  or  for  a  scientific  visualization.  ATM  may 
provide  a  higher-bandwidth  network  environment  for  these  works.  Taking  these 
improvements  into  account,  recommendations  for  future  work  may  be  as  follows: 

•  Distance  learning  applications  of  MBone/Web  classrooms  must  be  used  more 
often  and  more  classrooms  must  be  buUt.  This  does  not  mean  that  it  is  necessary  to  replace 
VTC  rooms  with  MBone  classrooms,  or  stop  investing  in  VTC  rooms.  These  two  types  of 
classrooms  have  similar  purposes  but  are  not  identical.  Funding  new  MBone  classrooms 
ought  to  be  included  in  the  future  business  plans  at  the  schools.  Adding  MBone  support  to 
existing  VTC  classrooms  may  provide  the  best  of  both  worlds. 

•  Using  MBone  with  virtual  environments  needs  to  be  experimented  with  more 
seriously.  This  will  be  a  strong  emphasis  in  next  generation  distributed  networks.  There 
are  many  important  applications  in  virtual  environments.  In  particular,  more  research  must 
be  done  combining  virtual  environments  with  video/audio  tools  and  MBone.  MBone  must 
be  used  together  with  3D  graphics  applications. 

•  Multicast  ATM,  ATM  WAN,  and  ATM  LAN  applications  need  further  work. 
There  are  many  problems  but  the  promise  of  ATM  in  support  of  internetworking  remains 
strong. 

•  An  interesting  application  of  Web/MBone  classrooms  might  be  to  employ 
language  interpreters  on  multiple  audio  channels  with  multilingual  versions  of  home 
pages. 
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APPENDIX  A.  CONFIGURING  COMPUTERS  FOR  A  NEW  SUBNET 


When  the  computers  change  their  subnets  for  any  reason,  they  have  to  be  assigned 
new  IP  numbers  in  the  subnet.  Once  receiving  the  new  IP  number  for  a  computer,  this 
change  must  be  done  in  the  new  subnet.  It  is  usually  done  by  changing  /etc/hosts  file, 
where  all  IP  numbers  and  symbolic  names  are  stored. 

The  /etc/hosts  file  is  the  oldest  and  simplest  way  to  map  names  to  IP  addresses. 
Each  line  starts  with  an  IP  address  and  continues  with  the  various  symbolic  names  by 
which  that  address  is  known.  A  major  disadvantage  of  the  /etc/hosts  file  is  that  the  data  it 
contains  must  be  replicated  on  every  machine  that  wants  to  use  symbolic  names. 
Therefore,  various  schemes  that  allow  a  single  version  of  the  hosts  file  to  be  kept  in  a 
control  location  are  used  in  networks. 

The  Domain  Name  System  (DNS)  is  one  of  these  schemes.  DNS  uses  Berkeley 
Internet  Name  Domain  (BIND)  system.  BIND  is  a  program  that  is  usually  included  in  all 
new  UNIX  versions.  This  server  runs  a  daemon  called  “named.”  Different  operating 
systems  have  different  file  names  in  DNS.  However,  generally  there  are  two  resolution 
files  for  hosts.  One  is  for  resolution  from  IP  address  to  symbolic  name  and  the  other  is 
from  symbolic  name  to  IP  address.  In  our  subnet,  they  were  “addrs.63”  for  IP-to-name, 
and  “hosts.stl”  for  name-to-IP.  These  and  other  mapping  files  are  located  under  /etc/ 
domain. 

For  adding  new  computers  to  a  subnet,  their  /etc/resolv.conf  file  must  be  corrected 
according  to  the  new  domain  name  server.  We  will  talk  more  about  this  file  later.  On  the 
server  side,  the  two  address  resolution  files  mentioned  above  must  be  corrected  to  include 
the  IP  addresses  and  symbolic  names  of  the  new  computers.  The  important  thing  is  to 
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change  the  serial  number  of  these  files  after  making  a  correction.  The  serial  number  is 
basically  a  date  group  for  the  last  effective  change.  The  subsequent  process  for  DNS 
change  is  to  re-activate  the  system  by  writing  “kill  -HUP  ‘cat  /etc/named.pid”’(in  Sun 
system)  as  a  command.  Again  these  file  configuration  and  commands  are  SGI  specific.  For 
different  computer  types,  related  manuals  must  be  checked. 

The  other  system  for  sharing  hosts  files  is  Sun’s  Network  Information  System 
(NIS).  NTS  is  not  only  used  for  sharing  /etc/hosts  file  but  also  used  for  sharing: 
/etc/passwd 
/etc/group 
/etc/networks 
/etc/services 
/etc/protocols 
/etc/aliases 
/etc/rpc 
/etc/netgroup 

In  systems  using  NIS,  different  update  procedures  are  necessary  for  connecting  to 
a  new  network.  Most  operating  systems,  such  as  HP-UX,  IRIX,  SunOS,  OSF/1,  ESDI 
support  NIS  [Nemeth  95].  In  this  system,  basically  the  machine  asks  the  server  machine 
for  any  entries  in  the  above  files.  If  the  client  machine  is  moved  to  a  new  network,  it  will 
not  be  able  to  find  the  NIS  server,  and  will  fail  in  a  number  of  surprising  ways.  NIS  maps 
(the  result  of  a  process  of  making  contents  of  the  files  by  the  server  as  to  be  seen  through 
the  network)  are  preprocessed  by  the  ndbm  extensible  hashing  routines  to  improve  the 
efficiency  of  lookups.  Since  ndbm  allows  only  one  “key”  to  be  associated  with  each  entry 
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a  system  file  has  to  be  translated  into  several  NIS  maps.  For  instance,  /etc/passwd  file  is 

translated  into  two  maps  called  “passwd.byname”  and  “passwd.byuid”.  The  former  is  used 

»  _ 

to  look  up  entries  by  user  name,  and  the  latter  to  look  up  entries  by  UID  (User  ID) 

[Nemeth  95]. 

First  thing  to  do  with  the  computers  that  changes  subnet  is  to  correct  /var/yp/ 
ypdomain  file  that  has  NIS  domain  name.  The  new  domain  name  must  be  written  in  that 
file.  As  a  second  step,  /etc/hosts  file  of  the  NIS  server  must  be  collected  to  include  new 
computers’  IP  addresses  and  names.  It  is  also  necessary  to  tell  the  machine  just  connected 
to  the  network  where  to  send  packets  for  routing.  For  SGI  machines,  we  changed  /etc/ 
rc2.d/S31network  file  to  show  the  default  route  when  the  computer  does  not  know  what  to 
do.  In  the  /etc/resolv.conf,  we  should  order  the  systems  that  the  host  machine  will  look  at 
to  include  NIS.  Now  we  have  both  DNS  and  NIS  in  our  “resolv.conf  ’  file.  For  IRIX 
operating  system  used  in  SGI  machine,  “hostresorder”  magic  word  is  used  to  make  an 
order  of  the  systems  that  will  be  checked  when  an  IP  address,  or  other  sorts  of  files  needed 
by  the  client.  When  we  write  “hostresorder  nis  bind  local”  this  means,  first  check  nis,  then 
bind  and  then  local  files.  If  we  want  to  include  /etc/passwd  file  into  NIS  password  map,  we 
need  to  put  a  plus  “+”  sign  in  a  line  under  the  users  passwords  in  that  file.  The  last  step 
with  NIS  is  to  re-activate  NIS  by  running  “ypmake”  command  at  the  server. 

However,  if  you  choose  the  easiest  way  and  use  your  local  files,  then  the  process 
gets  simpler.  In  this  case: 

•  Change  your  computer’s  name  in  etc/sys_id  with  the  new  one. 

•  Change  /etc/resolv.conf  to  appear  as: 

“hostresorder  local  bind  nis 
domainserver  your  new  Domain  Server” 

•  Turn  off  NIS  by  changing  /etc/config/yp  content  to  “off’. 

•  Add  computer’s  new  name  and  domain  to  /etc/hosts  file. 
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•  Add  new  gateway  address  to  /etc/rc2.d/S3  Inetwork  file  by  adding 
“route  add  net  default  ‘gateway  address’  threshold  (usually  1)” 

If  the  last  one  does  not  work  for  some  reason  and  you  cannot  connect  to  anywhere, 

then  try  to  write  the  same  sentence  in  the  command  line.  This  may  work  until  you  reboot 

the  computer. 

This  is  just  a  network  connection  part  of  a  new  configuration.  We  also  need  to  use 
mail,  telnet,  ftp,  printer  utilities  etc.  in  the  new  network.  These  are  made  by  mounting 
these  programs  to  NFS  (Network  File  System).  That  system  basically  allow  the  computers 
share  files  in  the  network.  I  will  not  go  in  to  details  of  NFS  configuration,  because  this 
goes  beyond  the  limits  of  this  appendix.  One  important  issue  is  that,  you  should  make  sure 
the  /usrAocal/bin  files  match  up.  Typically  you  will  have  /usr/local/bin  NFS  mounted  in 
the  old  network.  When  you  move,  aU  the  /usr/local/bin  programs  will  go  away.  You  need 
to  back  up  the  appropriate  files  that  are  installed,  such  as  MBone  tools,  Web  browsers  etc., 
with  the  correct  version,  usually  under  /usr/local  directory  on  the  local  disk. 
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APPENDIX  B.  MBONE  RELATED  INFORMATION 


This  appendix  contains  useful  information  about  important  aspects  of  MBone, 
including  mailing  lists,  kernel  and  mrouted  software  download  sites,  MBone  desktop 
application  sites,  and  MBone  related  information  sites  respectively. 

MBone  mailing  lists: 


The  followings  are  the  participating  networks’  e-mail  addresses 


AlterNet 

CERFnet 

CICNet 

CONCERT 

Cornell 

JANET 

JvNCnet 

Los  Nettos 

NCAR 

NCSAnet 

NEARnet 

OARnet 

PSCnet 

PSInet 

SESQUINET 

SDSCnet 

SURAnet 

UNINETT 


ops@uunet.uu.net 

mbone@cerf.net 

mbone@cic.net 

mbone@  concert.net 

swb@nr-tech.cit.corneU.edu 

mbone-admin@noc.ulcc.ac.uk 

multicast@jvnc.net 

prue@isi.edu 

mbone@  near.  ucar.  edu 

mbone@cic.net 

neamet-eng@nic.near.net 

oarnet-mbone@  oar.net 

pscnet-admin@psc.edu 

mbone@nisc.psi.net 

sesqui-tech@  sesqui.net 

mbone@sdsc.edu 

mbone@sdsc.edu 

mbone-no@  uninett.no 


MBone  request  addresses  for  your  region  to  be  added  to  MBone  mailing  lists  for 
purposes  of  coordinating  setup  of  tunnels,  etc: 


mbone-eu: 

mbone-jp: 

mbone-korea: 

mbone-ca: 

mbone-na: 

mbone-oz: 

mbone-sg: 

mbone-uk: 

mbone: 


mbone-eu-request@  sics.se 

mbone-jp-request@wide.ad.jp 

mbone-korea-request@  co  smos.kaist.  ac.kr 

canet-mbone-request@canet.ca 

mbone-na-request@isi.edu 

mbone-oz-request@intemode.com.au 

mbone-sg-request@lincoln.technet.sg 

mbone-uk-request@cs.ucl.ac.uk 

mbone-request@  isi.edu 


Europe 

Japan 

Korea 

Canada 

North  America 

Australia 

Singapore 

UK 

other 


85 


These  lists  are  primarily  aimed  at  network  providers  who  would  be  the  top  level  of 
the  MBONE  organizational  and  topological  hierarchy.  The  mailing  list  is  also  a  hierarchy; 
mbone@isi.edu  forwards  to  the  regional  lists,  then  those  lists  include  expanders  for 
network  providers  and  other  institutions.  Mail  of  general  interest  should  be  sent 
mbone@isi.edu,  while  regional  topology  questions  should  be  sent  to  the  appropriate 
regional  list. 

For  all  Remote  Conferencing  related  issues,  subscribe  to: 
rem-conf-request@  es.net 

For  all  Conference  Control  related  issues,  subscribe  to: 
confctrl-request@isi.edu 

For  Radio  multicasts  on  MBone,  subscribe  to: 
vat-radio-request@  elxr.jpl.nasa.  gov 

For  RSVP  discussions,  subscribe  to: 
rsvp-request@  isi.edu 

For  Integrated  Services  issues,  subscribe  to: 
int-serv-request@isi.edu 


MBone  kernel  and  mrouted  software  download  sites: 

Version  3.8  of  Mrouted  and  Version  3.5  of  IP  multicast  OS  kernel  extensions  are 
available  at  the  following  sites. 

For  all  platforms,  http:llwww.merit.edulnet-researchlmbonelindexlplatform.html 
For  SGI,  ftp: llftp.sgi.com 

For  Solaris,  ftp: //ftp. uoregon.edu,  and ftp://playground.sun.com 
For  DEC-Alpha  running  OSFl  Vl.Q,  ftp://chocolate.pa.dec.com 
For  FreeBSD  ftp:/ /ftp. pare xerox.com 

For  HPAJX  9. 05,  ftp://ftp.parcxerox.com 
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MBone  desktop  application  software  download  sites: 


For  all  platforms 

http://www.merit.edu/net-research/mbone/indexlplatform.html 

For  the  Unix  OS  platform: 

Audio  Conference  Tool  (VAT  4.0): 
ftp://ftp.ee.lbl.gOv/conferencing/vat/alpha-test/vat-4.0* 

Audio  Conference  Tool  (Nevot): 
ftp://gaia.cs.umass.edu/pub/hgschulz/nevot 

Video  Conference  Tool  (NetVideo): 
ftp://parcftpjcerox.eom/pub/net-research/nvbin-3.3* 

Video  Conference  Tool  (IVS): 

ftp://zenon.inria.fr/ivs/rodeo/ivs/version3 .3m3/ivs3  3m3-* 
Video  Conference  Tool  (Vic  2.7): 

ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/*-vicbin-2.7.* 

Shared  WhiteBoard  Tool  (wb): 

ftp :// ftp.ee.  lbl.gov/conferencing/wb/wb-1 .5  7* 

IMM  (JPEG  Images): 

ftp://ftp.hawaii.edu/paccom/imm-3. 3/imm-* 

Shared  Mosaic 
ftp://ftp.eit.com 

Session  Directory  Rendezvous  Tool  (sd): 
ftp  ://ftp  .ee.  lbl.gov/ conferencing/ sd/sd-1 .13* 

SDR 

ftp  ://ftp  .parcjcerox.com/pub/net-research/apps/sdr 

MMCC  Rendezvous  Software: 
ftp://ftp.isi.edu/confctrl/mmcc/ . 

MBone  applications  for  the  Macintosh 

Video  Conference  Tool  (Cu-SeeMe)  (no  multicast  support) 
ftp://gated.cornell.edu/pub/video/Mac.CU-SeeMe* 
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Maven  Audioconferencing  Tool  (no  multicast  support) 

ftp:llkl2 .cnidKorglpublMaclDir-SoundstufflMaven-*.sea.bin  (MacBinary) 


MBone  applications  for  PC/Windows 

Video  Conference  Tool  (Cu-SeeMe)  (no  multicast  support) 
ftp:/lgated.comell.edulpubfvideolPC.CU-SeeMe* 

Vic,  Vat,  Nv,  and  Sdr 

ftp  .ilftp  .ee.lbl. gov!  conferencing 

Sd,  Vat,  Nv 

ftpillftp.nus.sgIpubIzlIEE/MBONE 


MBone  related  information  sites: 

The  JPS  MBONE  Page  in  England 
http.i/www.cl.cam.ac.ukimbonel 

RIPE  MBone  WG  Page 
http:llwww.it.kth.sel~e93  jndalmbonelripewgl 

The  AT&T  MBONE  Page 
http:Hwww.research.att.com/mbone-faq.html 

MBone/IP  Multicast  Tools 
ftp :/ /agate. lut.ac.ulc/pub/mbone/ 

Naval  PostGraduate  School  MBone  information  page 
ftp://taurus.cs.nps.navy.mil/pub/mosaic/nps_mosaic.html 

Geneva  University  MBone  page 
http://www.unige.ch/seinf/mbone.html 

NLM  MBone  Page 

http://www.nlm.nih.gov/reports.dir/multicasting.dir/DOCS.dir/ 
multicast _details.html 

Digital  MBone  Page 

http:/ tchocolate.pa.dec.com/mbone 

SigNet  Home  Page 
http://www.acm.uiuc.edu/signet/ 


APPENDIX  C.  ABBREVUTIONS 


AAL 

ATM  Adaptation  Layer 

ARPA 

Advanced  Research  Project  Agency 

ATM 

Asynchronous  Transfer  Mode 

ATMARP 

ATM  Address  Resolution  Protocol 

AUV 

Autonomous  Underwater  Vehicle 

BAGNET 

Bay  Area  Gigabit  Testbed  NETwork 

BAYNET 

Bay  Area  Network 

BBS 

Bulletin  Board  Systems 

BIND 

Berkeley  Internet  Name  Domain 

CalREN 

California  Research  and  Education  Network 

CANARIE 

Canadian  Network  for  the  Advancement  of  Research,  Industry 
and  Education 

CBone 

Cyberspace  Backbone 

CBR 

Constant  Bit  Rate 

CBVE 

Chesapeake  Bay  Virtual  Ecosystem  Model 

ccm 

Consultative  Committee  on  International  Telephone  and 
Telegraph-Now  ITU 

CGF 

Computer  Generated  Forces 

CLP 

Cell  Loss  Priority 

CRC 

Cyclic  Redundancy  Control 

CS 

Convergence  Sublayer 

CSUMB 

California  State  University  Monterey  Bay 

DIS 

Distributed  Interactive  Simulations 

DNS 

Domain  Name  System 

DS-n 

Digital  Signal  level  n 

ESPDU 

Entity  State  PDU 

GFC 

Generic  Flow  Control 

HTTP 

Hypertext  Transfer  Protocol 

IETF 

Internet  Engineering  Task  Force 

IGMP 

Internet  Gateway  Message  Protocol 

IP 

Internetworking  Protocol 

ITU 

International  Telecommunications  Union 

I-WAY 

International  Wide-Area  Year 

LAN 

Local- Area  Network 

LIS 

Logical  IP  Subnetwork 

LSVE 

Large-Scale  Virtual  Environment 

MARS 

Multicast  Address  Resolution  Server 

MBA 

Monterey  Bay  Aquarium 

MBARI 

Monterey  Bay  Aquarium  Research  Institute 

MB  one 

Multicast  Backbone 

MICE 

Multimedia  Integrated  Conferencing  for  European  Researchers 

MOSPF 

The  Multicast  Extensions  to  Open  Shortest  Path  First 

mrouter 

multicast  router 

NBMA 

Non-Broadcast  Multi-Access 
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NFS 

Network  File  System 

NHRP 

Next  Hop  Resolution  Protocol 

NHS 

NHRP  Server 

NIC 

Network  Interface  Card 

NIS 

Network  Information  System 

NNI 

Network-to-Network  Interface 

NFS 

Naval  Postgraduate  School 

NPSNET 

NPS  Network 

NSA 

National  Security  Agency 

NTON 

National  Transparent  Optical  Network 

nv 

Network  Video 

OC-n 

Optical  Carrier  level  n 

OCRInet 

Ottawa  Carleton  Research  Institute  net 

PBX 

Private  Branch  eXchange 

PDU 

Protocol  Data  Unit 

PT 

Payload  Type 

PVC 

Permanent  Virtual  Circuit 

ROLC 

Routing  Over  Large  Clouds 

SAF 

Semi- Automated  Forces 

SAR 

Segmentation  And  Reassembly 

SDH 

Synchronous  Digital  Hierarchy 

SEAL 

Simple  and  Efficient  Adaptation  Layer 

SIMNET 

SIMulator  NETworking 

SONET 

Synchronous  Optical  NETwork 

STL 

System  Technology  Lab 

STRICOM 

Simulation  Training  and  Instrumentation  Command 

STS-n 

Synchronous  Transport  Signal  level  n 

SVC 

Switched  Virtual  Circuit 

UCSC 

University  of  California,  Santa  Cruz 

UID 

User  ID 

UNI 

User-to-Network  Interfaces 

UPS 

Uninterruptable  Power  Supply 

VBR 

Variable  Bit  Rate 

VCI 

Virtual  Circuit  Identifier 

VPI 

Virtual  Path  Identifier 

VRML 

Virtual  Reality  Modeling  Language 

vrtp 

virtual  reality  transfer  protocol 

VTC 

Video  Tele  Conferencing 

WAN 

Wide-Area  Network 

WWW 

World  Wide  Web 
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APPENDIX  D.  ON-LINE  AVAILABILITY  OF  THESIS  PRODUCTS 


Postscript  and  html  formats  of  this  thesis  are  available  at 
http:llwwwMlMps.ruivy.mill~iirgltamerltkesis.html. 
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APPENDIX  E.  BUILDING  AND  RUNNING  MBONE/WEB 


CLASSROOM 

This  appendix  documents  the  connection  configuration  of  an  MBoneAVeb 
classroom  from  a  more  technical  and  detailed  perspective.  The  first  part  is  the 
configuration  part  and  the  second  part  is  a  user  reference  to  run  the  classroom  and 
necessary  MBone  tools. 

The  ways  to  determine  the  hardware  requirements  and  hardware,  software,  and 
topology  are  explained  in  Chapter  IV  and  Chapter  VII  respectively.  In  this  part,  the  author 
documents  necessary  information  for  those  who  want  to  get  an  MB  one/Web  classroom 
working  in  their  school.  Audio/video  connections  of  the  MBone/Web  classroom  are 
shown  in  Figure  E.l. 

1.  How  to  make  connections  in  the  classroom. 

a.  Connect  the  wireless  microphone  to  the  video  camera. 

Wireless  microphones  are  made  of  two  separate  parts.  One  is  the  receiver 
part,  and  the  other  is  the  transmitter  part.  On  the  video  cameras,  there  is  usually  a  jack  for 
external  microphones.  Connect  one  end  of  your  wireless  microphone  cable  into  this  jack. 
Plug  the  other  end  of  the  cable  to  the  “audio  output”  jack  on  the  receiver  part  of  the 
wireless  microphone  (don’t  turn  on  anything  yet!).  Plug  the  antenna  into  the  “antenna” 
jack.  You  will  see  the  necessary  information  about  the  other  part  of  the  wireless 
microphone  set  later  on. 
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Figure  E.l  MBone  Classroom  Connections 


b.  After  putting  your  video  camera  over  the  tripod,  you  should  plug  the 
power  adapter’s  cable  into  the  camera. 

Take  the  cables  and  connect  them  into  the  adapter’s  back  panel  according 
to  the  Figure  E.2.  If  you  need  connectors  for  different  types  of  cable  (you  usually  do. 
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because  it  changes  from  camera  to  camera)  provide  these  connectors.  Put  a  blank  tape  into 
the  camera  and  set  the  “normal”  or  “record”  position  on  the  camera.  This  does  not 
necessarily  mean  that  you  should  start  recording.  There  is  usually  a  record  selector  on  the 
cameras.  This  is  important  because  otherwise  you  can  not  use  the  wireless  microphone  at 
all. 


ADAPTER’S  BACK  PANEL  CONNECTIONS 


1  VIDEO  AUDIO  1 

OUT 

OUT 

rcaO 

1 

O  RCA 

1  - 

T 

TO  VCR 

T 

TO  VCR 

Figure  E.2  Video  Camera  Power  Adapter’s  Back  Panel 
c.  Make  the  connections  in  the  vcr’s  back  panel  according  to  Figure  E.3. 


VCR’S  BACK  PANEL  CONNECTIONS 


FROM 

ADAPTER 

(CAMCORDER) 

AUDIO 

O  RCA 

IN 

VIDEO 

BNcO 

IN 

TO 

PROJECTOR 

RCA 

BNC  Oq^— 

FROM 

ADAPTER(CAMCORDER) 


TO^ 

PROJECTOR 


Figure  E.3  VCR’s  Back  Panel  Connections 


d.  Make  the  connections  in  the  projectors  back  panel  according  to 


Figure  E.4. 


I  have  used  “video  in  1”  part  on  the  back  panel. 
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PROJECTOR’S  BACK  PANEL  CONNECTIONS 


FROM 

VCR 

VIDEO  INI 

TO 

MOMTOR 

FROM 

VCR 

RCA  RCA 

AUDIO  IN  AUDIO  OUT 

TO 

MONITOR 

Figure  E.4  Projector’s  Back  Panel  Connections 
e.  Make  the  connections  in  the  TV  monitor’s  back  panel  according  to 


Figure  E.5. 


I  have  used  “line  A”  part  on  the  back  panel. 


TV  MONITOR’S  BACK  PANEL  CONNECTIONS 


VIDEO 

FROM 

LINE  A 

PROJECTOR 

TO 

f  I  OTPT  T3TvT/~' 

INDY^ 

1  )  UUi  J5JNC 

FROM 

PROJECTOR 

_ 

AUDIO 

_/^LEFT 

RCA 

RIGHT 

00 

TO 

INDY 


Figure  E.5  TV  Monitor’s  Back  Panel  Connections 


/.  Make  the  connections  in  Indy’s  back  panel  according  to  Figure  E.6. 
Indys  have  only  video  input  and  no  video  output.  So  this  issue  must  be 
taken  into  consideration  when  making  these  kind  of  configurations.  I  assume  that  you  have 
an  installed  Indy  camera  in  the  system. 
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INDY’S  BACK  PANEL  CONNECTIONS 


FROM  FROM  TV  FROM 


MIKE  MONITOR  INDY  DIC 

MANY  MANY  |  CAMERA 

ITAL 

RCA 

♦  i, 

?  ,a-  c 

)  c 

Figure  E.6  Indy’s  Back  Panel  Connections 


g.  Now  plug  all  the  power  cords  of  the  equipment,  turn  them  on. 

You  should  turn  all  of  them  on  to  have  the  system  working. 

h.  Turn  on  the  receiver  part  of  the  wireless  microphone. 

You  should  turn  the  volume  knob  to  the  right,  and  hear  a  “click”  sound. 
Also  you  should  check  the  battery  lamp.  To  turn  on  the  transmitter  part  of  wireless 
microphone,  you  should  slide  the  button  on  this  part  to  the  opposite  side  of  “off.”  You  will 
need  1-2  sets  of  batteries  per  day  of  use. 

2.  How  to  work  with  the  MBone  tools 

a.  Login  to  the  computer  if  it  is  not  already  logged  in. 

b.  In  the  unix  shell  window,  write  ‘‘sdr^’  to  run  the  MBone  application 

program. 

c.  You  should  see  a  window  that  shows  all  the  MBone  sessions 


(Figure  E.7). 

If  you  want  to  join  one  of  them,  just  double  click  on  the  session,  then  skip 

to  step  g. 
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Figure  E.7  Session  Directory  Window. 


d.  If  you  need  to  create  a  new  session,  click  the  *^New”  button. 

e.  On  the  “Create”  window  (Figure  E.8)  you  will  see , 

Fill  the  name  of  the  “Session  Name”  and  the  “Description”  parts  by  writing 
a  name  and  a  short  description  of  the  session.  Click  “video”  button  and  choose  the  video 
software  by  clicking  and  choosing  one  under  “Format”  column.  Make  sure  that  in  the 
“Scope”  part,  “Site”  is  highlighted  unless  you  are  sure  that  you  want  to  make  a  regional  or 
global  MBone  session.  When  you  are  finished  click  the  “Create”  button  to  create  the  new 
session. 

/.  Return  to  step  c  and  follow  the  instructions. 

g.  When  the  session  is  opened,  you  should  see  a  “Session  Information” 
window  (Figure  E.9). 
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Figure  E.8.  Create  New  Session  Window  in  Sdr 


h.  When  you  click  **StartAll”  button  in  Figure  E.9,  you  should  see  two 
different  windows. 

One  is  video  tool  window  (“vie”  in  our  example),  and  the  other  is  “Select  a 
tool”  window  (Figure  E.IO).  Click  the  “vat”  or  “rat”  button  (“vat”  in  our  example)  on  the 
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window.  When  you  click  “Start  tool”  button  you  will  see  “visual  audio  tool”  (vat)  window 
(Figure  E.  1 1).  Click  the  “menu”  button  on  the  window.  You  should  click  on  the  “full 
duplex”  at  the  upper  part  of  the  window  (Figure  E.12).  Then  “dismiss”  the  window. 


Figure  E.9.  Session  Information  Window 


Figure  E.IO.  Select  a  Tool  Window. 
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Figure  E.ll.  Visual  Audio  Tool  (vat)  Window. 


i.  You  can  switch  the  microphones  from  “mike”  button  on  the  visual 
audio  control  panel  (Figure  E.13). 

Also  you  should  click  on  the  “talk”  above  the  “mike”  button  to  use  full 
duplex  mode  which  means  you  can  send  and  hear  at  the  same  time. 

j.  Click  on  the  “menu”  on  the  “vie”  window  (Figure  E.14). 

k.  Choose  the  camera  you  will  use  by  clicking  the  “port”  button  at  the 
middle  of  the  window  (Figure  EJ5),  and  selecting  the  “digital”  for  Indy  camera,  or 
“analog”  for  video  camera. 

l.  Click  on  the  “transmit”  button  at  the  top  of  the  window  to  send  your 
picture  to  the  network. 
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Figure  E.12.  Vat  Menu  Window. 


Figure  E.13.  Microphone  Button  on  Vat  Window. 
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Figure  E.14.  Vic  Window. 


Figure  E.15.  Vic  Menu  Window. 
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m.  You  should  see  near  end  picture  on  the  “vie”  window  (Figure  E.16). 
If  you  click  on  the  picture,  you  can  enlarge  the  picture. 


Figure  E.  1 6.  Near  End  Picture  in  Vic  Window. 

3.  How  to  operate  in  a  built  and  connected  classroom 

a.  Turn  on  the  computer,  external  harddisk,  TV  monitor,  video  camera. 
Put  a  blank  tape  in  it  Make  sure  that  “rec”  led  is  on.  Otherwise  push  the 

“rec”  button  on  the  panel.  This  “rec”  is  not  the  same  as  “record”  button  which  is  red  and 
let  the  camera  record.  Remove  the  cap  from  the  lens. 

b.  Turn  on  die  receiver  part  of  the  wireless  microphone. 

Turn  up  the  volume  control  to  the  right.  Make  sure  the  red  led  is  turned  on, 
and  “low  bat”  led  is  off. 

c.  Turn  on  the  transmitter  part  of  the  wireless  microphone. 

Slide  the  “xmtr  off’  button  to  the  right  and  keep  the  other  button  on 
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“audio”.  Make  sure  the  red  led  is  turned  on,  and  “low  bat”  led  is  off. 


d.  TV  monitor  must  be  showing  *‘UNE  A”  on  its  front  panel. 

e.  Now  all  the  equipment  should  be  turned  on,  and  you  should  see  what 
the  camera  is  recording  on  the  tv  monitor. 
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APPENDIX  E  PLANNING  AND  MANAGING  A  MULTICAST 
SESSION  FOR  AUV  96  CONFERENCE 

This  appendix  documents  what  was  done  in  the  planning  and  during  the  AUV  96 
conference.  The  first  part  examines  the  preparation  for  the  conference,  determination  of 
the  requirements  both  for  equipment  and  for  people.  The  second  part  describes  the 
hardware/software  configuration  for  the  conference  and  lessons  learned. 

1.  Preparation  for  the  Conference 

It  is  always  good  to  make  a  list  first  of  what  is  needed  in  the  conference.  This  list 
should  include  both  the  equipment  and  the  people.  Two  weeks  prior  to  the  conference,  a 
conference  room  walk-through  must  be  done  to  become  familiar  with  the  location  where 
the  equipment  wUl  be  setup.  This  is  especially  important  for  final  configuration  issues, 
since  what  is  expected  is  not  always  the  same  as  what  people  prepare  or  have  in  the 
conference  room.  After  the  walk-through  and  discussions  with  the  people  in  charge  of  the 
conference  rooms,  a  final  configuration  can  be  made. 

The  last  step  prior  to  the  conference  is  to  test  aU  the  equipment  that  will  be  used  in 
the  conference  with  its  final  hardware/software  configuration.  This  testing  permits 
effective  troubleshooting  and  dramatically  decreases  the  time  spent  for  the  same  purpose 
during  the  conference.  Testing  the  equipment  may  reveal  some  additional  missed  points. 
In  AUV  96,  we  used  two  Airlan  wireless  bridges  to  connect  conference  rooms  to  one  of 
the  subnets  in  NPS.  Therefore  it  was  a  good  idea  to  test  the  bridges  before  the  conference 
but  in  the  same  location  as  they  would  be  used  in  the  conference.  The  bridges  were  the 
most  important  part  of  the  job.  If  they  didn’t  work,  nothing  could  be  done  with  MBone, 
since  there  were  no  network  connections  in  the  conference  room. 
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Two  or  three  days  before  the  conference,  all  the  equipment  was  packed  and  made 
ready  for  moving  to  the  hotel.  The  next  day,  the  equipment  was  moved  to  the  conference 
room,  all  the  configurations  set  as  planned,  and  tests  performed.  A  watch  bill  is  needed  for 
people  deployed  in  the  conference.  For  each  session,  one  person  needs  to  work  with  the 
computer  (MBone  tools),  one  person  needs  to  operate  the  video  camera  (since  we  had 
only  one  video  camera)  and  one  person  is  a  substitute  either  for  the  computer  operator,  or 
for  the  video  camera  operator.  So  three  people  were  used.  It  is  advisable  to  have  two 
different  watches  in  a  day  period,  since  it  is  not  so  easy  to  stay  there  for  eight  horns  and  be 
fully  alert  and  cautious. 

Equipment  requirements  for  AUV  96  conference  were  as  follows: 

♦  Two  Indy  workstations,  with  at  least  one  presenter.  Presenter  is  very  useful  if  the 
speaker  from  your  school  wants  to  show  a  home  page  or  anything  using  a  Web  browser. 

♦  One  PC  with  MBone  tools  and  network  tools  installed  (win95). 

♦  One  UPS  (not  a  small  one,  it  can  support  at  least  6-8  plugs). 

♦  One  video  camera  (this  may  change  depending  on  the  configuration  you  made). 

♦  Two  VCRs  (one  is  used  by  the  speakers,  the  other  is  used  by  you.  It  is  good  to 
have  at  least  one  SVHS  VCR,  since  it  has  more  input  and  output  jacks  than  regular  ones). 

♦  Two  TV  monitors,  one  big  screen  and  one  small  screen  like  13”.  The  big  one  is 
useful  either  for  the  cameraman  to  see  what  he/she  is  shooting,  or  audiences  to  see  the 
speaker  closer,  and  watch  the  video  tape  that  the  speaker  plays.  The  small  one  is  necessary 
on  the  computer  desk  to  see  what  the  video  is  recording  and  what  you  are  multicasting. 
The  number  of  TV  monitors  also  increases  when  the  number  of  video  cameras  increases. 

♦  One  tripod  (it  is  one  for  each  video  camera). 
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•  One  video  projector  for  the  VCR  that  is  used  by  speakers. 

•  One  prerecorded  test  video  tape  to  see  if  the  configuration  related  to  VCR  is 
working. 

•  One  pair  of  walky-talkies  or  cellular  phones  (at  least),  this  is  extremely 
important,  when  you  are  testing  or  working  with  the  wireless  bridges,  on  the  roof.  You 
need  to  talk  to  the  people  down  in  the  conference  center  to  verify  that  the  network  is 
working. 

•  One  cellular  phone  to  get  in  touch  with  the  school  for  the  network  confirmation 

again. 

•  One  wireless  mike  as  a  backup  for  house  sound  system  and  spare  batteries. 

•  One  head  phone  to  listen  to  the  sound  you  are  transmitting  fi:om  MBone.  This  is 
also  important  since  usually,  you  may  disturb  audiences  if  you  try  to  listen  to  the  sound 
directly  from  the  monitor. 

•  A  long  Ethernet  cable  and  connection  tools  to  make  your  own  Ethernet 
connections  as  you  wish. 

•  Three  or  four  power  strips  to  make  use  of  a  limited  number  of  power  outlets  for 
your  large  numbers  of  equipment. 

•  Blank  video  tapes,  labels  etc. 

2.  Conference  Period 

With  the  requirements  above,  the  connection  schema  of  the  conference  room  is 
shown  in  Figure  F.l.  Antennas  used  with  the  wireless  bridges  are  directed  antennas,  so 
they  need  to  see  each  other  with  correct  polarization  (means  that  they  need  to  be 
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symmetrically  aligned,  either  vertically  or  horizontally).  All  the  audio  is  connected  to  the 
audio  mixer  provided  by  the  conference  center.  The  audio  was  taken  from  that  audio  mixer 
to  the  S  VHS  VCR.  One  good  thing  about  the  audio  mixer  was  that  it  was  close  to  the 
system.  The  operator  could  turn  up  or  turn  down  the  volume  of  individual  microphones,  if 
they  interfered  with  each  other.  The  good  thing  about  the  VCR  used  was  that  it  had  two 
input  and  two  output  audio/video  jacks.  This  gave  an  important  flexibility  with 
connections.  The  microphone  stand  was  placed  in  the  middle  of  the  auditorium.  A  large 
TV  monitor  was  used  by  the  cameraman  to  see  what  he  was  shooting  since  the  view  finder 
of  the  camera  was  too  small  to  look  through  for  hours.  The  same  monitor  was  also  used  by 
the  audiences  who  were  on  the  far  side  of  the  room,  to  see  the  speakers,  slides,  or  video 
tapes  better. 

3.  Lessons  Learned  from  the  Conference 

Some  notes  can  be  listed  as  follows: 

♦  Speakers  should  be  requested  to  prepare  their  slides  in  a  predetermined  font  and 
size.  Some  slides  were  really  impossible  to  see  through  MBone,  even  when  maximum 
zoom  was  used.  Actually  these  slides  couldn’t  be  read  by  near-end  audiences  either.  Our 
rule  of  thumb  for  slides  over  the  MBone  is  that  good  slides  look  fine  and  bad  slides  look 
worse. 

•  We  originally  thought  that,  in  order  to  multicast  a  good  picture  quality  we  should 
set  the  vie  quality  according  to  the  object  that  is  shot.  For  instance,  if  a  slide  is  shot,  then 
we  might  increase  the  quality  by  decreasing  the  amount  down  to  1  on  the  vie  menu  (Figure 
F.2). 
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Antenna  and 
bridge  in  NPS 
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Figure  F.l  AUV  96  Conference  Configuration  and  Connections 


Figure  F.2  Vic  Menu  ^ndow 


*  There  were  several  problems  with  the  network.  These  were  not  usually  hardware 
problems.  Since  there  are  many  subnets  and  linked  tunnels  between  these  subnets,  when  a 
system  administrator  tries  to  install  a  new  router,  or  a  daemon,  he/she  may  delete  a  tunnel 
or  forget  to  re-ran  the  mrouter  daemon.  That  may  cause  a  variety  of  problems.  Fortunately, 
we  found  the  network  administrator  by  phone  to  make  the  network  run  properly  again  in 
each  case.  As  a  consequence,  it  is  a  good  idea  to  send  e-mails  to  all  system  administrators 
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at  the  school  informing  them  of  session  time. 

♦  Labeling  all  cables  and  equipment  before  tearing  down  when  you  are  finished 
with  the  conference  can  save  a  lot  of  time  in  matching  cable  to  machine  later. 

•  If  battery  powered  equipment  is  used,  then  be  sure  that  all  the  batteries  are  fully 
charged  and  there  are  also  some  spares. 
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APPENDIX  G.  PRICE  COMPARISON  OF  MBONE  AND  VTC 


The  following  information  provides  a  simple  price  comparison  of  different  types 
of  MBone  classrooms  with  different  types  and  quality  of  VTC  classrooms.  One  important 
thing  to  point  is  this  comparison  does  not  include  a  quality  comparison.  Since  VTC  is  a 
commercial  system,  its  quality  is  supposed  to  be  higher  than  the  MBone  while  Web/ 
MBone  classroom  has  greater  functionality  than  VTC  classroom  due  to  Web  connectivity. 
Our  purpose  is  to  show  that  the  MBone  is  an  effective  and  affordable  system  that  can  be 
used  by  any  public  school,  not  necessarily  to  show  the  highest  quality  or  the  most 
functional  one. 

The  NFS  VTC  classrooms  costs  $45,000  and  contains  the  equipment  listed  in 
Figure  G.l  [Walsh,  96]. 


• 

VTC  system 

FictureTel  4000. 

FC 

For  word  processing  or  presentation  purposes. 

♦ 

Imux 

Necessary  for  bandwidth  higher  than  112Kbps. 

# 

TV  Monitor 

Three  TV  monitors  are  used. 

• 

Fax 

Used  for  documentation  transfer  to  the  far  end. 

♦ 

Document  camera 

Used  for  viewing  slides  or  PC  presentation. 

♦ 

Folycam 

The  main  camera  that  is  used  in  the  VTC  classroom. 

♦ 

Auxiliary  camera 

The  second  camera  that  is  used  in  the  classroom. 

• 

VCR 

Two  for  recording  and  one  for  playing. 

• 

NTl 

Terminator  for  ISDN. 

♦ 

UFS 

Uninterrupted  Fewer  Supply. 

Auto  microphones 

Microphones  in  the  classroom. 

♦ 

Scan  convertor 

Converts  FC  image  to  the  digital  data  for  ISDN. 

Figure  G.l.  NFS  VTC  Classroom  Equipment  List. 


Various  configmations  of  a  Web/MBone  classroom  are  shown  in  Figure  G.2. 
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System  ID 

Price($) 

Classroom 

Classroom 

Receive-only 

(Indy) 

(PC) 

(Minimum  PC) 

Video  Camera 

0.5K 

X 

X 

TV  monitor 

0.7K 

X 

X 

Indy  (w/presenter) 

17K 

X 

Pentium  (PC) 

1.5K 

X 

X 

Digital  camera 

0.15K 

Video  capture  card 

0.2K 

X 

LCD  presenter 

2K 

X 

X 

VCR 

0.2K 

X 

X 

Wireless  microphone 

0.15K 

X 

X 

Overhead  projector 

0.2K 

XX* 

XX* 

X 

Projection  screen 

0.15K 

XX* 

XX* 

X 

TOTAL 

$19,250** 

$5,950***  $3,850 

*  Two  of  them  were  used. 

**  It  costs  $18,750  when  digital  camera  is  used  instead  of  video  camera. 
***  It  costs  $5,600  when  digital  camera  is  used  instead  of  video  camera. 


Figure  G.2.  Web/MBone  Classroom  Equipment  and  Price  List. 


It  should  be  noted  that  Figure  G.2  disregards  the  cost  for  configuring  the 
classrooms  themselves  for  distance  learning  purposes,  i.e.  building  special  walls  or 
installing  directed  lights.  In  our  MBone  classrooms  we  didn’t  pay  for  these  kinds  of 
expenses.  For  a  VTC  classroom,  it  is  essential  to  upgrade  the  room  configuration  for 
adequate  audio/video  quality.  Internet  connection  charges  are  separate  and  likely  identical 
in  each  case. 

The  following  numbers  give  the  cost  ratio  of  each  system  being  used. 

Web/MBone  classroom  (SGI  Indy)/VTC  classroom  at  NPS:  42% 

Web/MBone  classroom  (PC  receive)/VTC  classroom  at  NPS:  8% 
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Using  these  ratios,  we  can  say  that  a  Web/MBone  classroom  using  SGI  Indy  can 
be  42%  as  expensive  as  a  VTC  classroom  at  NFS,  and  a  Web/MBone  classroom  using  a 
PC  in  receive-only  mode  can  be  8%  as  expensive  as  a  VTC  classroom  at  NPS.  Even 
though  there  is  currently  no  MBone  video  tool  to  transmit  from  a  PC  with  a  video  capture 
card,  by  assuming  there  will  be  in  the  near  future,  ratios  of  a  Web/MBone  classroom  using 
a  PC  in  with  a  capture  card  is  as  follows: 

Web/MBone  classroom  (PC  transmit)/VTC  classroom  at  NPS:  12% 

Consequently,  PC  Web/MBone  classrooms  appear  to  be  affordable  for  schools. 
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